[Python-Dev] PEP 407: New release cycle and introducing long-term support versions (original) (raw)

Matt Joiner 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 important because:

  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 considered reliable.

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 mailing list