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

[Raymond Hettinger]

Brett Cannon wrote:

> 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.


Well intentioned, but futile.   Each case ultimately gets decided on its 
merits.  Any one reason for inclusion or exclusion can be outweighed by 
some other reason.  There isn't a consistent ruleset that explains 
clearly why decimal, elementtree, email, and textwrap were included 
while Cheetah, Twisted, numpy, and BeautifulSoup were not. 

Overly general rules are likely to be rife with exceptions and amount to 
useless administrivia.  I don't think these contentious issues can be 
decided in advance.  The specifics of each case are more relevant than a 
laundry list of generalizations.


> 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.


Nice guideline, but the decimal module did not meet that test.  For AST, 
the stability criterion was tossed and the ultimate API is still in 
limbo.  Itertools went in directly.  However, the tried and true mxTools 
never went in, and the venerable bytecodehacks never had a chance.


>
> Second, the code must follow Python coding guidelines.

We already have a PEP for that.


>
> Third, a PEP discussing why the module should go in.

We don't need a PEP for every module.  If the python-dev discussion says 
we want it and Guido approves, then it is a done deal.


>
> Now, another thing is backwards compatibility.

Isn't there already a PEP where people can add portability restrictions 
(i.e. having decimal continue to work on Py2.3?