<div dir="ltr">[A copy from <a href="https://github.com/python/typing/issues/495">https://github.com/python/typing/issues/495</a> to get more people's attention to this issue.]<br><p>I'm wondering if we should remove <code>typing</code> from the stdlib. Now's the time to think about this, as the feature freeze for 3.7 is about 12 weeks away.</p>
<p>Cons:</p>
<ul><li>People have to depend on a PyPI package to use typing (but they do anyway for <code>typing_extensions</code>)</li><li>It's a backward incompatibility for users of Python 3.5 and 3.6 (but the <code>typing</code> module was always provisional)</li></ul>
<p>Pros:</p>
<ul><li>The <code>typing</code> module can evolve much faster outside the stdlib</li><li>We could get rid of <code>typing_extensions</code> (and maybe even <code>mypy_extensions</code>)</li></ul>
<p>If we don't do this I worry that we're entering a period where many new typesystem features end up in <code>typing_extensions</code> and users will be confused about which items are in <code>typing</code> and which in <code>typing_extensions</code> (not to mention <code>mypy_extensions</code>). Anything new to be added to typing (e.g. <code>Const</code>, <code>Final</code>, <code>Literal</code>, or changing ABCs to Protocols) would have to be added to <code>typing_extensions</code> instead, and users would be confused about which features exist in which module. Moving <code>typing</code> out of the stdlib can make things potentially simpler, at the cost of an extra <code>pip install</code> (but they'll need one anyway for <code>mypy</code>).</p>
<p>Thoughts?</p><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>