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.do...@python.org> wrote: > On 03Nov2017 0915, Victor Stinner wrote: > >> Hi, >> >> 2017-11-03 15:36 GMT+01:00 Guido van Rossum <gu...@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@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com