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 namespaces. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------