"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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4