[Python-ideas] Python 3.9.9 - The 'I Have A Dream' Version

[Chris Angelico]

On Tue, Apr 14, 2015 at 10:14 PM, Simon Kennedy <sffjunkie at gmail.com> wrote:
> * Splitting the standard library in twain. stdlib = 'baselib' + 'extlib'.
>   - baselib = Enough to start up a Python environment / install pip.
>   - extlib = The rest of the current stdlib. Changes more frequently than
> the baselib.

This could work, and answer Steven's objections, if what you have is
three tiers: the two you describe, plus leaving PyPI as it already is.
All you have to do is formalize a process for updating the extlib,
such as:

* Point releases of Python may make backward-compatible changes to the
extlib (eg expand PEP 434 to cover more packages); or
* extlib packages are duplicated onto PyPI, and can thus be
updated/backported; or
* extlib packages are distributed via a dedicated update mechanism,
and get updated as an entire unit

or something of the sort. Basically, the extlib and the baselib
together comprise the "Python Standard Library", and you can depend on
having all of its modules on all installations (subject to platform
concerns of course).

> * A new tool called pippin to manage the extlib

Which might be the third option listed above.

> * Formalising what a package index is

Not sure what this would mean. Are you talking about turning PyPI into
just one of many package indexes, the way deb and rpm repositories are
distributed?

> * Addressing a Python project's lifecycle.

How?

> * Configuration handling

How?

> * Removing the use of 'lib' suffixes from almost all packages.

Breaks backward compatibility for minimal benefit. Why do it?

> * Claiming any name in PyPi starting with 'py'

I suppose this is part of putting the extlib there? IMO that shouldn't
be necessary. Conflicts are won by the first package to get published.

There's going to be STRONG pushback against backward-incompatible
changes. Py2->Py3 is still transitioning, and we don't want to be
eternally managing multiple codebases or warped compatibility code.
Imagine how it'd look:

try:
    from url.parse import unquote # Python 4
except ImportError:
    try:
        from urllib.parse import unquote # Python 3
    except ImportError:
        from urllib import unquote # Python 2

You could bury it behind an "import twentyfour", but it's still a
mess. And this is assuming there's identical functionality in the
modules - otherwise you need even more shims.

I would recommend focusing on incremental changes. If you want to see
the stdlib divided such that more packages can be upgraded more
frequently, that might be doable without breaking everything. Renaming
"virtual environment" to simply "environment" and treating the base
installation as "just another environment" ought to be doable too
(though you'd have to do up a detailed proposal to be sure). The
renamings probably just aren't worth doing, but maybe you could
convince people to add alternate names and deprecate the old ones.
There's no particular reason for it all to be packaged together into
one monster proposal :)

ChrisA