On Sat, Feb 18, 2012 at 6:54 PM, Nick Coghlan
While it's obviously not the ideal, forking orphaned stdlib modules and publishing new versions on PyPI can be an *excellent* idea. The core development team is generally a fairly conservative bunch, so unless a module has a sufficiently active maintainer that feels entitled to make API design decisions, our default response to proposals is going to be "no". One of the *best* ways to change this is to develop a community around an enhanced version of the module - one of our reasons for switching to a DVCS for our development was to help make it easier for people to extract and merge stdlib updates while maintaining their own versions. Then, when you come to python-ideas to say "Hey, wouldn't this be a good idea?", it's possible to point to the PyPI version and say: - people have tried this and liked it - I've been maintaining this for a while now and would continue to do so for the standard library
Some major (current or planned) updates to the Python 3.3 standard library occurred because folks decided the stdlib solutions were not in an acceptable state and set out to improve them (specifically, the packaging package came from the distutils2 fork, which continues as a backport to early Python versions, and MRAB's regex module has been approved for addition, although it hasn't actually been incorporated yet). In the past, other major additions like argparse came about that way.
A few other stdlib modules have backports on PyPI by their respective stlib maintainers so we can try out new design concepts *before* committing to supporting them in the standard library.
A published version of doctest2 that was designed to be suitable for eventual incorporation back into doctest itself (i.e. by maintaining backwards compatibility) sounds like it would be quite popular, and would route around the fact that enhancing it isn't high on the priority list for the current core development team.
Well said, Nick. That's worth putting in the devguide. -eric