[Python-ideas] Moving development out of the standard library

[Nick Coghlan]

On 09/06/10 21:34, David Stanek wrote:
> On Wed, Jun 9, 2010 at 7:08 AM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> Something we may want to seriously consider is maintaining parallel releases
>> of packages indefinitely when the benefits are deemed to justify the
>> additional overheads.
>>
>
> I had a very similar thought. Why not have all the real development of
> those packages happen outside of the standard lib and just grab the
> latest stable version when cutting a new version of Python.
>
> Namespaces are fine, but I'd be happy enough with a way for these
> packages to show up on the Python path before the stdlib.

Another parallel that occurs to me is the stable/testing/unstable 
distinction in Debian - if you want rock solid (but old) you stick with 
stable, if you want comparatively cutting edge you go with unstable and 
testing splits the difference.

Ubuntu's "normal release" vs "Long Term Support release" distinction is 
also worth thinking about. Most home desktop users will upgrade every 6 
months (modulo rocky transitions like the upgrade to KDE 4), while 
corporate users will wait for the next LTS to arrive.

To bring that back to a Python context and revisit the proposal that 
Guido rejected for biennial Python releases with annual standard library 
releases, suppose that, instead of the standard library itself having 
annual releases, there was a python-dev maintained (or even third-party 
maintained, python-dev blessed) "pybackports" project.

The idea being, that package would not only make many new standard 
library features of the current Python release available on widely used 
previous versions, but also make upcoming features of the *next* Python 
release available on the current version. The periods of support would 
be shorter to reflect the faster release

Third party libraries and applications could then either target the 
"rock solid" market and depend solely on the standard library, or go for 
the "latest and greatest" crowd and require pybackports.

Make no mistake, something like this would be quite a bit of work, but 
it would be far from impossible and could go a long way towards fighting 
the impression that the standard library is the place where modules go 
to die.

TLDR version:

Year A: Python 3.x release, pybackports 3.x.0 release
Year B: No Python release, pybackports 3.x.5 release (with 3.y features)
Year C: Python 3.y release, pybackports 3.y.0 release
Year D: No Python release, pybackports 3.y.5 release (with 3.z features)
...etc

Unlike Python itself, Pybackports would not provide bugfix support for 
prior releases (since it would only be for the latest-and-greatest 
crowd, those that want the longer support should stick with the standard 
library).

Something to think about, anyway.

Cheers,
Nick.

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