Remove typing.py from the stdlib?

[gvanrossum]

We should seriously consider this, since it would make updates to the module much easier.

[vlasovskikh]

I believe that we should keep typing in the stdlib and introduce a new "bleeding-edge" or "early access" version of typing that is available on PyPI and becomes merged into stdlib with every major release of CPython. We could call it typing2 or future_typing or somehow.

People interested in new hot features would use something like:

from typing2 import NewType, Type

BTW it could have been a better way of adding typing.Text than introducing it in Python 3.5.2.

I think having typing in the stdlib is important for the following reasons:

• The default semantics of functions annotations is now type hints, so the module necessary for writing type hints should be in the core language distribution
• You've mentioned that you wouldn't object if new stdlib modules included type hints. It won't be possible without the typing module in the stdlib
• With typing in the stdlib people can rely on the stable API for type hinting universally available for Python 3.5+. It helps making type hinting more widespread

[gvanrossum]

Good points all. Maybe we should just pick a name for the new module? (I don't like `typing2` much.)

[vlasovskikh]

Possible names:

• future_typing
• next_typing

It would be nice to ask more people for ideas.

BTW we should mention in PEP 484 that the compatible type checkers should support the new "early access" typing module from PyPI.

[prechelt]

Yes, typing2 sounds like something that is not backwards-compatible, which we want to avoid (both the sounding and the being).

I think future_typing is appropriate: People will know from __future__ import and draw all the correct conclusions from the similarity.

[ilevkivskyi]

@vlasovskikh I was going to propose the same idea, but then read your comment :-) I think future_typing sounds good.

[JukkaL]

I can see how this could be useful. Would the PyPI typing package continue to track the stdlib version?

future_typing sounds pretty clear but it's a pretty long module name, especially for something that would be used in pretty much every file that uses annotations.

Also, how about typing_dev, typing_future or typing_next (to put emphasis on typing -- this might be better for readability when skimming code)? The first name would put emphasis on this being bleeding edge stuff, some of which might change before being adopted in stdlib.

[vlasovskikh]

I like typing_dev and typing_future.

[agronholm]

The asyncio package has the same problem. Has it been solved there?

[gvanrossum]

For asyncio we decided to keep it. Per Python 3.6, PEP 3156 is no longer provisional.

I think there's not enough support for removing typing.py, and a few good reasons to keep it, so let's keep it. I also think typing.py should stop being provisional as of Python 3.6.0.