[Python-Dev] PEP 413: Faster evolution of the Python Standard Library

[Matt Joiner]

Why not cut the (external) stdlib before each minor release?

Testing new language features is not the role of a public release, this is
no reason to require ownership on a module.

Evidently some modules have to ship with core if they are required (sys),or
expose internals (os, gc). Others are clearly extras, (async{ore,hat},
subprocess, unittest, select).

There are so many third party modules languishing because inferior forms
exist in the stdlib, and no centralized method for their recommendation and
discovery. Breaking out optional parts of the stdlib is an enabling step
towards addressing this. I would suggest Haskell, node.js and golang as
examples of how stdlibs are minimal enough to define basic idiomatic
interfaces but allow and encourage extension.
On Feb 25, 2012 10:53 AM, "Brett Cannon" <brett at python.org> wrote:

>
>
> On Fri, Feb 24, 2012 at 21:08, Matt Joiner <anacrolix at gmail.com> wrote:
>
>> I think every minor release should be fully supported. The current rate
>> of change is very high and there's a huge burden on implementers and
>> production users to keep up, so much so that upgrading is undesirable
>> except for serious enthusiasts.
>>
>> Include just the basics and CPython specific modules in the core release
>> and version the stdlib separately. The stdlib should be supported such that
>> it can be installed to an arbitrary version of Python.
>>
>
> That idea has been put forth and shot down. The stdlib has to be tied to
> at least some version of Python just like any other project. Plus the
> stdlib is where we try out new language features to make sure they make
> sense. Making it a separate project is not that feasible.
>
>
>>  Better yet I'd like to see the stdlib become a list of vetted external
>> libraries that meet some requirements on usefulness, stability and
>> compatibility (PEP), that get cut at regular intervals. This takes the
>> burden away from core, improves innovation, allows for different
>> implementations, and ensures that the Python package management system is
>> actually useful.
>>
>
> That's been called a sumo release and proposed before, but no one has
> taken the time to do it (although the 3rd-party releases of Python somewhat
> take this view). Thinning out the stdlib in favour of the community
> providing solutions is another can of worms which does not directly impact
> the discussion of how to handle stdlib releases unless you are pushing to
> simply drop the stdlib which is not possible as Python itself depends on it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120225/0b2750f7/attachment.html>