[Python-ideas] Moving typing out of the stdlib in Python 3.7?

Nick Coghlan ncoghlan at gmail.com
Sat Nov 4 23:46:59 EDT 2017

On 5 November 2017 at 06:22, Guido van Rossum <guido at python.org> wrote:
> On Sat, Nov 4, 2017 at 7:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Perhaps typing could switch to being a bundled module, such that it
>> had its own version, independent of the Python standard library
>> version, but was still present by default in new installations?
> 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?

You'd be blazing new trails, but you'd be blazing them with a
single-file pure Python module without any binary dependencies outside
CPython itself, which is the simplest possible precedent setting
scenario we could hope for.

I can think of a couple of possible approaches you could take,
depending on how you want to manage development on the typing module

= External dev =

* Typing moves entirely out of the CPython source tree, with a
separate issue tracker, repository, branch structure, etc (which you
already have)
* We add a "_bundled" directory to the CPython source tree in 3.7+ and
put a typing sdist archive there
* the release process PEP gains a "Confirm the bundled modules are up
to date" step
* the CPython build process is updated to use a venv to generate wheel
files from bundled sdists
* regrtest gains a "bundled" resource (and/or dedicated command line option)
* when asked to test bundled modules, regrtest spins up a test venv,
installs pip and the bundled modules, then runs the tests for those
* ensurepip gains the ability to also install bundled wheel files
* the Windows and Mac OS X installers start including the typing wheel file

= In tree dev =

* Similar to external dev for testing and distribution
* Source code would stay in the main CPython tree and track CPython
branch structure
* The sdist file would be built by CPython's build process, rather
than being checked in

The external dev model is probably a better fit for your use case,
though, since you'd like something that you can readily keep
consistent across all supported 3.x versions (or at least 3.7+), and
that's harder to do when you have multiple copies of the source code
to keep in sync (vs having a single development branch where you run
your CI testing across all supported Python versions).

The external dev option also establishes a more useful precedent,
since we could use it to officially migrate ongoing distutils
maintenance into the setuptools project, and then bring it back via
bundling of setuptools. Similarly, PEP 434 (which already exempts IDLE
from the usual "No new features in maintenance releases" rules) could
potentially be switched over to handling IDLE as an independently
updated bundled application.

The above idea is somewhat similar to what I suggested for the
recommended modules list in
but the difference is that to simplify the testing and installer
building process, we'd bundle a suitable source archive in the git
repo, rather than requiring PyPI access.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list