[Python-Dev] PEP 407: New release cycle and introducing long-term support versions
anacrolix at gmail.com
Thu Jan 19 01:42:00 CET 2012
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> The main reason is changes in the library. We have been getting complaints
> about the standard library bitrotting for years now, and one of the main
> reasons it's so hard to a) get decent code into the stdlib and b) keep it
> maintained is that the release cycles are so long. It's a tough thing for
> contributors to accept that the feature you've just implemented will only
> be in a stable release in 16 months.
> If the stdlib does not get more reactive, it might just as well be cropped
> down to a bare core, because 3rd-party libraries do everything as well and
> do it before we do. But you're right that if Python came without batteries,
> the current release cycle would be fine.
I think this is the real issue here. The batteries in Python are so
1) The stability and quality of 3rd party libraries is not guaranteed.
2) The mechanism used to obtain 3rd party libraries, is not popular or
Much of the "bitrot" is that standard library modules have been
deprecated by third party ones that are of a much higher
functionality. Rather than importing these libraries, it needs to be
trivial to obtain them.
Putting some of these higher quality 3rd party modules into lock step
with Python is an unpopular move, and hampers their future growth.
>From the top of my head, libraries such as LXML, argparse, and
requests are such popular libraries that shouldn't be baked in. In the
long term, it would be nice to see these kinds of libraries dropped
from the standard installation, and made available through the new
distribute package systems etc.
More information about the Python-Dev