[Python-3000] We should write a PEP on what goes into the stdlib

[Brett Cannon]

Right now a discussion is going on in python-dev about what is reasonable
for special needs of developers who bring in modules to the stdlib.  This of
course brings up the idea of slimming down the stdlib, having sumo releases,
etc.

That makes me think perhaps we should start thinking about collectively
coming up with guidelines (which end up in a PEP; and yes, I am volunteering
to write it) on deciding what is needed to accept a module into the stdlib.
We can then use this to go through what is already there and trim out the
fluff already there and get a list going of what will end up disappearing
early on so people can know long in advance.

Now this has nothing to do with a stdlib renaming or anything.  This is
purely about figuring out what is required for accepting a module and for
pruning out what we don't want that we currently have.


So, to start this discussion, here are my ideas...

First, the modules must have been in the wild and used by the community.
This has worked well so far by making sure the code is stable and that the
API is good.

Second, the code must follow Python coding guidelines.  This means not just
proper formatting and naming, but also that good unit tests are included as
well.  It also means that the module name might need to be renamed.
Documentation must also be provided in the proper format before acceptance.
All of this must be done *before* anything is checked in (use a branch if
needed to hold the work on the transition).

Third, a PEP discussing why the module should go in.  Basically, a
documented case for why the module should be distributed in Python.  It also
gives python-dev a central document to read and refer to when voting on
whether something should be let into the stdlib.  Can also document
differences between the public version and the one in the stdlib.

Fourth, the contributor must have signed a contribution agreement.

Fifth, contributors realize that Python developers have any and all rights
to check in changes to the code.  They can do something like how Barry
maintains external email releases and document that in the PEP.  This is
probably  one of the more contentious ideas laid out here.  But we need to
worry about keeping the stdlib easily maintained since python-dev takes on
responsibility for code once it's checked in so we need to keep this as
simple as possible.  Basically this eliminates PEP 360 for Py3K.


Now, another thing is backwards compatibility.  Do we worry about
portability to older versions like we do now with PEP 291, or do all new
modules checked in give up the right to force developers to keep the code
compatible to a certain version?  This is another ease of maintenance/nice
to external release issue.

And that external release/ease of maintenance is going to be the sticky
point in all of this.  We need to find a good balance or we for scaring away
people from contributing code.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060612/6e5b2c70/attachment.htm