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.
Outside of a few exceptions (like ast or importlib) functionality in the standard library seldom relies on anything in a particular Python release; e.g., code might use conditional expressions, but it never *has* to use conditional expressions. The standard library that most people know and love is really the least common denominator of Python's that person has to handle; for someone writing an open source library that's probably 2.5, for someone using Zope 2 that's traditionally been 2.4, and if you have a controlled environment (e.g., internal development) maybe you can do 2.6.
I think there is a general consensus that functionality should not be tied to a Python release, but the results are ad hoc. That is, truly useful libraries that are added to the stdlib are backported, or more often were originally maintained as a library with backward compatibility before being integrated into the standard library. I think we should have a more formalized process about how this functionality is maintained, including a process that considers the years of ongoing maintenance and improvement that should happen on these libraries. (Most specifically without serious thought about this development process I am pessimistic about an orderly or positive inclusion of distutils2 in packaging workflows.)
Another alternative is to simply not make improvements to the standard library beyond a very well-defined set of appropriate functionality. This would be much closer to the status quo. Defining what categories would be "appropriate" would be contentious, I am sure, but would sharply focus future discussions.
--
Ian Bicking | http://blog.ianbicking.org