[Python-ideas] Moving development out of the standard library
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