[Python-Dev] Remove typing from the stdlib

[Lukasz Langa]

> On Nov 6, 2017, at 8:01 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> As I indicated in my comment there, I'm now wondering if there might
> be an opportunity here whereby we could use the *dataclasses* module
> to define a stable non-provisional syntactically compatible subset of
> the typing module, and require folks to start explicitly depending on
> the typing module (as a regular PyPI dependency) if they want anything
> more sophisticated than that (Unions, Generics, TypeVars, etc).

I have an issue open about essentially this idea:
https://github.com/python/typing/issues/496


The consensus is that this is too expensive to do this in time for Python 3.7. On the other hand, not doing anything is terrible in terms of usability: now users will be forced to use both `typing` (a frozen non-provisional version in the stdlib) and `typing_extensions` (new features that we couldn't add directly to `typing`).


This is the reason why Guido asked about moving `typing` out of the standard library. Currently it seems that the best thing that we can do is to ship an upgradeable version of `typing` with Python 3.7.0. There are many details to be figured out here:

1. Does that mean `typing` is going to be provisional forever? The answer is surprisingly "yes" since it makes sense to keep updating the bundled `typing` in 3.7.1, 3.7.2, etc. We need to update PEP 411 to talk about this new case.

2. Does that mean `typing` can now become backwards incompatible randomly? The answer should be "no" and already is "no". If you look at typing.py, it already ships in Python 3.6 with some crazy dances that makes it work even on Python 3.3.

3. Does that mean that Debian is going to rip it out and make people install a `python-typing` .deb? Sadly, probably yes. We need to figure out what that means for us.

4. How do we even version this library then? Probably like this: 3.7.0.0, 3.7.0.1, 3.7.1.0, and so on. But that depends on answers to the other questions above.

5. What will happen to typing_extensions and mypy_extensions? They can probably be folded into typing 3.7.0.0. This is a huge win for usability.

6. Where will we track issues for it? Which repo will be the source of truth? Fortunately, we already have https://github.com/python/typing/ <https://github.com/python/typing/>


There's more things to figure out for sure. And the clock is ticking. But this is a great case study to figure out since more packages in the standard library could use a release model like this, and maybe in the future this will finally lead to unbundling of the standard library from the runtime. Yeah, it's a long shot and the dependency graph between libraries in the standard library is rather extensive. But this is the first step.

- Ł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/573319de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/573319de/attachment-0001.sig>