[Python-Dev] Remove typing from the stdlib

[Guido van Rossum]

A side note (I'm reading all responses but staying out of the discussion):

No static checker should depend on the *contents* of typing.py, since it's
just a bunch of runtime gymnastics to allow types to be evaluated at
runtime without errors, with a secondary goal of making them introspectable
(some folks don't even agree with the latter, e.g. Mark Shannon).

Static analyzers should be able to make strong *assumptions* about what
things defined there mean -- in mypy such assumptions are all over the
place, based on the full name of things -- it never reads typing.py. (It
reads typing.pyi from typeshed, but what's there is ignored in many cases
too.)



On Fri, Nov 3, 2017 at 10:00 AM, Steve Dower <steve.dower at python.org> wrote:

> On 03Nov2017 0915, Victor Stinner wrote:
>
>> Hi,
>>
>> 2017-11-03 15:36 GMT+01:00 Guido van Rossum <guido at python.org>:
>>
>>> Maybe we should remove typing from the stdlib?
>>> https://github.com/python/typing/issues/495
>>>
>>
>> I'm strongly in favor on such move.
>>
>
> I'm torn.
>
> If not having typing installed means you can't use "Any" or "Optional" in
> an annotation, that basically kills the whole thing. Some primitives need
> to be there.
>
> If annotations become glorified strings (which IMHO they should) and
> typing gains a function to parse those into type hints (which IMHO it
> should), then I'm in favour of splitting typing out. (Personally, if making
> every type hint a literal 'string' meant that I could avoid importing
> typing then I'd do it.)
>
> However, if typing is split out then its API (specifically, the contents
> of typing.__all__ and their semantic meaning (e.g. "Iterable" means
> something with an "__iter__" method)) needs to stay in PEPs.
>
> Static analysers using type hints encode much more information about these
> types than can be inferred statically from typing.py, which means the
> definitions should not change faster than Python x.*y*. Ideally, they would
> not change at all once released.
>
> For example, my static analyser has an existing object representing
> iterables, since we've been inferring iterables for years. When I parse a
> type annotation and see "typing.Iterable", I'm going to just substitute my
> own implementation - the definition in typing.py isn't going to be used (or
> be useful). And because it has to map across languages, it has to be a
> hard-coded mapping that can't rely on typing.py at all.
>
> Since the contents of typing.py will likely be completely ignored by my
> analyser, which means that I can't treat "whatever version of typing is
> installed" as ground truth. It needs to move slower or be purely additive.
> Being in the standard library is a nice easy way to ensure this - moving it
> out is a risk.
>
> That said, because I don't care about the contents of the file, all the
> heavy execution stuff can totally be moved out. If typing in the stdlib
> became very trivial definitions or just a set of names to support
> searching/editors/forward-refs, and typing out of the stdlib had the
> ability to convert annotations into an object model that provides rich
> runtime introspection, I'd also be fine. At least then the interface is
> highly stable, even if the implementation (for those who use it) changes.
>
> Cheers,
> Steve
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171103/ac5344d0/attachment.html>