[Python-ideas] Moving development out of the standard library
ncoghlan at gmail.com
Wed Jun 9 14:13:51 CEST 2010
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
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)
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
Something to think about, anyway.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas