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

Eric S. Raymond esr@thyrsus.com
Tue, 23 Jan 2001 06:08:06 -0500


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.

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?

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?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

I do not find in orthodox Christianity one redeeming feature.
	-- Thomas Jefferson