[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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
