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

[Brett Cannon]

On Wed, Jun 9, 2010 at 08:17, Ian Bicking <ianb at colorstudy.com> wrote:
> On Wed, Jun 9, 2010 at 6:38 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> On Wed, 9 Jun 2010 07:34:56 -0400
>> David Stanek <dstanek at dstanek.com> 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).