[Python-ideas] stdlib upgrades

[Jesse Noller]

On Tue, Jun 1, 2010 at 4:54 AM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> Hello,
>
> That's not a new idea, but I'd like to throw it here again.
>
> Some modules/packages in the stdlib are pretty isolated, which means
> that they could be upgraded with no
> harm, independently from the rest. For example the unittest package,
> or the email package.
>
> Here's an idea:
>
> 1 - add a version number in each package or module of the stdlib that
> is potentially upgradable
>
> 2 - create standalone releases of these modules/packages at PyPI, in a
> restricted area 'stdlib upgrades'
>     that can be used only by core devs to upload new versions. Each
> release lists the precise
>     Python versions it's compatible with.
>
> 3 - once distutils2 is back in the stdlib, provide a command line
> interface to list upgradable packages, and make
>     it possible to upgrade them
>
> 4 - an upgraded package lands in a new specific site-packages
> directory and is loaded *before* the one in Lib
>
> Regards
> Tarek


I dislike this more than I thought I would - I would rather have the
stdlib broken out from core and have it have more releases than the
whole of python then allowing for piecemeal "blessed" upgrades.
Allowing piecemeal upgrades of the stdlib means you have to say
something akin to:

"I support Python 2.6, with the upgraded unittest (2.6.1.3), socket
(2.6.1.2) and multiprocessing modules"

And so on. Sure, API compatibility should be "fine" - but we all know
that there are exceptions to the rule all the time, and that alone is
enough to put the nix on allowing arbitrary upgrades of individual
modules within the standard lib. For package authors, and users, the
simple "I support 2.6" statement is key. For corporations with strict
upgrade checks and verifications, the same applies.

jesse