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

[M.-A. Lemburg]

"Eric S. Raymond" wrote:
> 
> M.-A. Lemburg <mal@lemburg.com>:
> > > 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
> 
> Muttering "PEP 206" evades the fundamental problem rather than solving it.
> 
> Not that I'm saying Moshe hasn't made a valiant effort, within the political
> constraint that the BDFL and others seem unwilling to confront the deeper
> issue.  But PEP 206 is not enough.  Here is why:
> 
> 1. If the "Sumo" packaging ever happens, the vanilla non-Sumo version that
> Guido issues will quickly become of mostly theoretical interest -- because
> Red Hat and everybody else will move to Sumo instantly, figuring they have
> nothing to lose by including more features.
> 
> 2. If by some change I'm wrong about 1, the outcome will be worse;
> we'll in effect have fragmented the language, because there won't be
> consistency in what library stuff is available between Sumo and
> non-Sumo builds on the same platform.
> 
> 3. There are documentation issues as well.  It's already a blot on
> Python that the standard documentation set doesn't cover Tkinter.  In
> the Sumo distribution, the gap between what's installed and what's
> documented is likely to widen further.  Developers will see this as
> pointlessly irritating -- and they'll be right.
> 
> The stock distribution should *be* the Sumo distribution.  If we're really
> so terrified of the extra maintainence load, then the right fix is to
> mark some modules and documentation as "externally maintained" with
> prominent pointers back to the responsible people.

That's your POV, others think different and since this is not
a democracy, the Sumo distribution is a feasable way of satisfying
both needs.

There are a few other issues to consider as well:

* licensing is a problem (and this is also mentioned in the PEP 206)
  since some of the nicer additions are GPLed and thus not
  in the spirit of Python's closed-source friendliness which
  has provided it with a large user base in the commercial field

* packages authors are not all the same and some may not want
  to split their distribution due to the integration of their
  package in a Sumo-distribution

* the packages mentioned in PEP 206 are very complex and usually
  largish; maintaining them will cause much more effort compared
  to the standard lib modules and extensions

* the build process varies widely between packages; even though
  we have distutils, some of the packages extend it to fit
  their specific needs (which is OK, but causes extra efforts
  in getting the build process combined)

I'm not objecting to the Sumo-distribution project; to the 
contrary -- I tried a similar project a few years ago:
the Python PowerTools distribution which you can download
from:

	http://www.lemburg.com/python/PowerTools-0.2.zip

The project died quickly though, as I wasn't able to keep
up with the maintenance effort.

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