[Python-3000] Limitations of "batteries included"

[Guido van Rossum]

[Subject was: Removing email package until it's fixed]

I find there are pluses and minuses to the "batteries included"
philosophy. Not so much in the case of the email package (which I'm
sure will be back before 3.0 final is released), but in general, in
order for a package to be suitable for inclusion in the core, it must
have pretty much stopped evolving, or at least its evolution rate must
have slowed down to the same 18-24 month feature release cycle that
the core language and library experiences.

Take for example GUI packages. Tkinter is far from ideal, but there
are many competitors, none of them perfect (not even those packages
specifically designed to be platform-neutral). We can't very well
include all of the major packages (PyQt, PyGtk, wxPython, anygui) --
the release would just bloat tremendously, and getting stable versions
of all of these would just be a maintenance nightmare. (I don't know
how Linux distros do it, but they tend to have a large group of people
*just* devoted to *bundling* stuff, and their release cycles are even
slower. I don't think Python should be in that business.)

Database wrappers are in the same boat, and IMO the approach of
separately downloadable 3rd party wrappers (sometimes multiple
competing wrappers for the same database) has served the users well.

Or consider the major pain caused by PyXML (xmlplus), which tried to
pre-empt the namespace of the built-in xml package, causing endless
confusion and breakage.

Would anyone seriously consider including something like Django,
TurboGears or Pylons in a Python release? I hope not -- these all
evolve at a rate about 10x that of Python, and the version included
with a core distribution would be out of date (and a nuisance to
replace) within months of the core release.

I believe the only reasonable solution is to promote the use of
package managers, and to let go of the "batteries included" philosophy
where it comes to major external functionality. When it links to
something that requires me to do install a pre-built external
non-Python bundle anyway (e.g. Berkeley Db, Sqlite, and others), the
included battery is useless until it is "charged" by installing that
dependency; the Python wrapper might as well be managed by the same
package manager.

Now, there's plenty of pure Python (or Python-specific) functionality
for which "batteries included" makes total sense, including the email
package, wsgiref, XML processing, and more; it's often a judgement
call. But I want to warn against the desire to include everything --
it's not going to happen, and it shouldn't.

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