On Mon, Nov 6, 2017 at 5:27 PM, Barry Warsaw <barry@python.org> wrote:

Guido van Rossum wrote:

> This is beginning to sound like the most attractive solution. We could
> possibly do away with typing_extensions. Are there precedents of how to
> bundle a module in this way? Or is it going to be another special case like
> pip?

With my downstream consumer hat on, *if* we go with a bundling solution,
please make sure it's easy to unbundle. Downstream consumers may need
to do this for policy, security, etc. reasons, so making this too
difficult will mean delays in releases, convoluted hacks, policy
violations, or all of the above.

See as reference some of the hoops Debian has to go through to handle
ensurepip.

Having skimmed this thread and some others, I am going in the opposite direction. Moving typing.py out of the stdlib and then bundling it will cause too many problems, both psychological and technical.

Therefore I am withdrawing my idea of moving typing.py out of the stdlib, and replacing it with an extension of its (and PEP 484's) provisional status by at least one release cycle. This means that at least for the duration of 3.7 we'll be able to update typing.py pretty aggressively in bugfix releases.

See https://github.com/python/peps/pull/451 -- basically we only need a restricted interpretation of provisional, where we can add new features, but won't break backwards compatibility *for documented aspects of the API*. With PEP 560, we can then attempt to speed up the import of typing.py (hopefully 10x by the time 3.8 rolls around).

I propose that the schedule for typing.py's provisional status be added to PEP 563 (the __future__ import for annotations); I've got a PR with tentative update to PEP 484 ready (https://github.com/python/peps/pull/451).

--Guido van Rossum (python.org/~guido)