On Wed, Jun 9, 2010 at 08:17, Ian Bicking
On Wed, Jun 9, 2010 at 6:38 AM, Antoine Pitrou
wrote: On Wed, 9 Jun 2010 07:34:56 -0400 David Stanek
wrote: I had a very similar thought. Why not have all the real development of those packages happen outside of the standard lib and just grab the latest stable version when cutting a new version of Python.
-1. We have had too much trouble with externally-maintained modules such as elementtree and json. The Python SVN (or hg) tree should be the primary place where development takes place.
New releases could also be cut from the Python tree. I believe everyone here agrees that entering the standard library in any form should imply a greater sense of collective ownership of a package.
But this makes the assumption that core developers are going to choose to develop modules such that they can be released before the next release of Python goes out. There seems to be a lot of extrapolation from the fact that Michael takes the time to do unittest2 (which, now that I think about it, should probably have been named unittest_external or something as it really isn't a sequel to unittest, just an external release) and that Tarek is doing the initial development of distutils2 externally. Out of all the core developers that is not that many. Sure you could maybe toss in ElementTree, but that probably is it (e.g. simplejson only gets new releases when Bob fixes stuff for a new Python release or simply makes an external release of stdlib fixes). For me, importlib will never work in this environment. When new features in modules or the language come in I try to update code to use it when I can. That means that importlib is not going to have a stable release cycle outside of Python's. Nor am I going to be willing to change that practice as that makes development harder for me -- I don't want to have to check if some new feature has been made available externally -- and honestly more boring -- I like using the new features of the language as that helps make core development fun. The only way I see this working is for individual core developers to decide they want to keep a module dependent only on the last minor release of Python (or older). At that point you can try to convince the developers to use a common package name (stdlib, py, stdlib_ext, etc.) and then use namespace packages or pkgutil.extend_path to pull them in under the common package name to signify that they are "early" releases of the modules from the stdlib. That gives you an easier way to gauge usage as you can look at use of the package as a whole to see what kind of community pickup there is. If you can do that *and* show that there was a clear benefit to the community then you might have a chance to get more developers to participate in this development scheme. But in terms of a general python-dev policy, it simply won't happen as it is just too much extra work to force upon everyone (Nick seems to be the only one I can think of still throwing ideas out there, but even with that I don't know how much work he wants to put in).