[Python-ideas] Moving development out of the standard library

[Nick Coghlan]

On 08/06/10 02:35, Ian Bicking wrote:
> OK... after a bit of off-list discussion I realize what I am really
> concerned about with respect to the standard library wasn't well
> expressed.  So here's my real assertion:
>
>    There is no reason any new library or functionality should be tied to
> a Python release.
>

Rather than rehash the point Antoine has already made regarding 
dependency management, I'll mention the other key benefit of standard 
library inclusion:

   Inclusion of a module or package in the standard library makes sense 
when the benefits of having "One Obvious Way To Do It" simplifies 
teaching of Python and development and maintenance of future Python code 
sufficiently to justify the slower rate of release associated with 
standard library inclusion.

I'm one of those that believes that the volume of all currently written 
Python code is a small subset of the Python code that will ever be 
written, hence it makes sense to "raise the bar" in improving the 
quality of the baseline toolset provided to developers. Additions like 
argparse and the new futures module in PEP 3148, as well as historical 
additions like itertools, collections, ElementTree, simplejson, etc all 
serve that purpose well.

However, I *also* like the pattern that has emerged of many standard 
library modules being kept backwards compatible with previous Python 
releases, and sometimes even being separately released on PyPI (or 
elsewhere). This approach allows the "one obvious way" to be extended 
back to earlier Python versions, since eventual standard library 
inclusion is a big point in a module or package's favour, even if a 
developer isn't currently using the latest Python release.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------