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@gmail.com | Brisbane, Australia ---------------------------------------------------------------