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

[Guido van Rossum]

I'm coming late to this, and am folding all my comments in a single
email. Short version: Brett, please go ahead! Here are some comments.

[Raymond]
> 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.

Oh yes there is.  Just look at the names alone.  Also release cycles.

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

It still makes sense to have a list of guidelines.  (a) This tells
potential contributors how high the bar is set.  (b) This helps the
discussion if "fairness" is invoked (why did module X get accepted?).

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

Agreed (this is the only part where I disagree with Brett).  This is
not to say that a PEP wouldn't be helpful in some cases; but it's not
a requirement.  A PEP is helpful when it is likely that the discussion
will be long or contentious.

[Michael Chermside]
> I agree. If we have a PEP with rules for acceptance, then every time we
> don't follow those rules exactly we will be accused of favoritism. If
> we have informal rules like today and decide things on a case-by-case
> basis, then everything is fine.

I don't think that not having rules avoids accusations of favoritism.
There are many rules and guidelines that are being applied quite
consistently when something is proposed for stdlib inclusion (Brett
didn't even enumerate all of them; for example an oft-cited rule is
that the contributor must commit to maintaining the code for several
years).  It only makes sense to write these up in one place.  Of
course we shouldn't create the expectation that anything that matches
the rules is automatically accepted (that would be insane).

> Rather than a formal PEP, how about a wiki page

Absolutely not!  Wikis have no official status.  Not only can anybody
edit them; there's no process in place to remove them when they are
outdated.

[Talin]
> So what I would suggest, then, is the creation of a standard (in this
> legal sense) for what factors should be considered in deciding whether
> to include something in the stdlib.
>
> Moreover, the standard should be clearly labeled as such - to prevent
> people from interpreting the document as a set of hard rules that they
> can use to beat other people over the head with.

Sounds like a good idea.  Not so different from what I said above
about automatic acceptance based on matching the rules.

[Brett]
> At this point, I am dropping the PEP idea and I am going to make it a
> general doc at python.org/dev/ when a take my intro doc
> (http://www.python.org/dev/intro/) and break it out into individual
> docs for bugs, patches, committing, and getting things into the stdlib
> or language.

I think this is fine; but I don't think it would be wrong to do it as
a PEP.  Having a PEP makes it a bit easier for the community to
participate in discussing its contents, so I think I would have
favored a PEP, but the important thing is that the standard we apply
is documented somewhere.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)