[Python-ideas] Moving development out of the standard library
ncoghlan at gmail.com
Mon Jun 7 22:24:54 CEST 2010
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
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.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas