[Python-Dev] What does "batteries are included" mean?

[M.-A. Lemburg]

"Eric S. Raymond" wrote:
> 
> M.-A. Lemburg <mal@lemburg.com>:
> > All very well, but are sets really that essential to every
> > day Python programming ? If we include sets then we ought to
> > also include graphs, tries, btrees and all those other goodies
> > we have in computer science.
> 
> I use sets a lot.  And there was enough demand to generate a PEP.

Sure, but sets are fairly easy to implement using Python dictionaries
-- at least at the level normally needed by Python programs. Sets, queues
and graphs are examples of data types which can have many
different faces; it is hard to design APIs for these which meet 
everyones needs.
 
> But the wider question here is how seriously we take "batteries are
> included" as a design principle.  Does a facility have to be useful
> *every day* to be worth being in the standard library?  And if so,
> what are things like the POP3 and IMAP libraries (or, for that matter,
> my own shlex and netrc modules) doing there?

You can argue the same way for all kinds of extensions and
packages you find in the Vaults. That's why there's demand for
a different packaging of Python and this is what Moshe's
PEP 206 addresses:

	http://python.sourceforge.net/peps/pep-0206.html

> I don't think so. I think there are at least four different
> possible reasons for something to be in the standard library:
> 
> 1. It's useful every day.
> 
> 2. It's useful less frequently than every day, but is a stable
> cross-platform implementation of a wheel that would otherwise have to
> be reinvented frequently.  That is, you can solve it *once* and have a
> zero-maintainance increment to the power of the language.
> 
> 3. It's a technique that's not often used, and not necessarily stable
> in the face of platform variations, but nothing else will do
> when you need it and it's notably difficult to get right.  (popen2 and
> BaseHTTPServer would be good examples of this.)
> 
> 4. It's a developer checklist feature that improves Python's competitive
> position against Perl, Tcl, and other contenders for the same ecological
> niche.
> 
> IMO a lightweight set facility, like POP3 and IMAP, qualifies under 2 and 4
> even if not under 1 and 3.
> 
> This question keeps coming up in different guises.  I'm often the one to
> raise it, because I favor an aggressive interpretation of "batteries
> are included" that would pull in a lot of stuff.  Yes, this makes more
> work for us -- but I think it's work we should be doing.
> 
> While minimalism is an excellent design heuristic for the core language,
> I think it's a bad one for the libraries.  Python is a high-level language
> and programmers using it both expect and deserve high-level libraries --
> yes, including graphs/tries/btrees and all that computer science stuff.
> 
> Just as much to the point, Python competing against languages like
> Perl that frequently get design wins against it because of the
> richness of the environment *they* are willing to carry around.
> 
> Guido and Tim and others are more conservative than I, which would be
> OK -- but it seems to me that the conservatives do not have consistent
> or well-thought-out criteria for what to include, which is *not* OK.
> We need to solve this problem.
> 
> Some time back I initiated a library guidelines PEP, then dropped it
> due to press of overwork.  But the general question is going to keep
> coming up and we ought to have policy guidelines that potential
> library developers can understand.
> 
> Should I pick this up again?

Hmm, we already have the PEP 206 which focusses on the topic.
Perhaps you could work with Moshe to sort out the "which
batteries do we need" sub-topic ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/