<div dir="ltr"><div>A side note (I'm reading all responses but staying out of the discussion):<br><br>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).<br><br>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.)<br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 10:00 AM, Steve Dower <span dir="ltr"><<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03Nov2017 0915, Victor Stinner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
2017-11-03 15:36 GMT+01:00 Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we should remove typing from the stdlib?<br>
<a href="https://github.com/python/typing/issues/495" rel="noreferrer" target="_blank">https://github.com/python/typi<wbr>ng/issues/495</a><br>
</blockquote>
<br>
I'm strongly in favor on such move.<br>
</blockquote>
<br></span>
I'm torn.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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<wbr>, 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.<br>
<br>
Cheers,<br>
Steve<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/options/python-dev/guido%<wbr>40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>