(original) (raw)
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 Fri, Feb 24, 2012 at 21:08, Matt Joiner <anacrolix@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.