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

Nick Coghlan ncoghlan at gmail.com
Wed Jun 9 13:08:13 CEST 2010

On 09/06/10 19:05, Tarek Ziadé wrote:
> And "not putting distutils2 in the stdlib" is not the solution because
> this is a problem
> for all packages in there.
> That's exactly what unitest currently do (but with a new name "unittest2")
> and as soon as Python 2.7 final will be out, unittest will have the
> same problem:
> it won't be able to backport new features anymore under the same namespace.

Something we may want to seriously consider is maintaining parallel 
releases of packages indefinitely when the benefits are deemed to 
justify the additional overheads.

So, for example, many of the current features of unittest2 will be 
available in unittest in 2.7 and 3.2. This makes those features 
available to those that rely almost entirely on standard library 
functionality rather than third party packages. In the meantime, users 
of previous versions of Python can already use unittest2, and that 
package will work *without name conflicts* in both 2.7 and 3.2, even 
though many of its features have been added to the standard library.

unittest2 may then even go through a few external releases before being 
synced up again with the standard library's unittest when 3.3 comes around.

Something similar may turn out to be a good idea for distutils2: rather 
than consider the anticipated merge back into distutils prior to 3.3 the 
end of the road, instead continue to use distutils2 to release faster 
updates while evolving the API design towards 3.4.

Users then have the choice - the solid, stable standard library version, 
or the distinctly named, more rapidly updated PyPI version.

As others have suggested, this namespace separation approach could be 
standardised through the use of a PEP 382 namespace package so that 
users could choose between (e.g.) "unittest" and "distutils" and 
"cutting_edge.unittest" and "cutting_edge.distutils" (with the latter 
being the regularly updated, new features and all, PyPI versions, and 
the former the traditional stable API, bugfix-only standard library 
versions). That would probably be an improvement over the current ad hoc 
approach to naming separation for standard library updates.

I don't see any way to ever resolve the two competing goal sets 
(stability vs latest features) without permanently maintaining separate 


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

More information about the Python-ideas mailing list