Antoine wrote: >> The standard library is not about easeness of installation. It is >> about having >> a consistent fixed codebase to work with. I don't want to go >> Perl/CPAN, where you have 3-4 alternatives to do thing A which will >> never interoperate >> with whatever you chose among the 3-4 alternatives to do thing B. > > Currently in Python: > http://docs.python.org/lib/module-xml.dom.html > http://docs.python.org/lib/module-xml.dom.minidom.html > http://docs.python.org/lib/module-xml.sax.html > http://docs.python.org/lib/module-xml.parsers.expat.html > http://docs.python.org/lib/module-xml.etree.ElementTree.html > > The problem of "consistent fixed codebase" is that standards get > higher, so eventually those old stable modules lose popularity in > favor of newer, better modules.
Those are different paradigms of "doing XML". For instance, the standard library was missing a "pythonic" library to do XML processing, and several arose. ElementTree (fortunately) won and joined the standard distribution. This should allievate the need for other libraries in future. Instead of looking what we have inside, look outside. There are dozens of different XML "pythonic" libraries. I have fought in the past with programs that required large XML frameworks, that in turn required to be downloaded, built, installed, and *understood* to make the required modifictions to the programs themselves. This slowed down my own development, and caused infinite headaches before of version compatibilities (A requires the XML library B, but only versions < 1.2, otherwise you can use A 2.0, which needs Python 2.4+, and then you can use latest B; etc. etc. repeat and complicate ad-libitum). A single version number (that of Python) and a large fixed set of libraries anybody can use is a *strong* PLUS. Then, there is the opposite phenomenom, which is interesting as well. I met many perl programmers which simply re-invented their little wheel everytime. They were mostly system administrators, so they *knew* very well what hell the dependency chains are for both programmers and users. Thus, since perl does not have a standard library, they simply did not import *any* module. This way, the program is "easier" to ship, distribute and use, but it's harder to code, read, fix, and contain unnecessary duplications with everybody's else script. Need to send an e-mail? Why using a library, just paste chunks of cut&pasted mail headers (with MIME, etc.) and do some basic string substitution; and the SMTP protocol is easy, just open a socket a dump some strings to it; or you can use 'sendmail' which is available on any UNIX (and there it goes portability, just because they did not want to evaluate and choose one of the 6 Perl SMTP libraries... and rightfully so!). > Therefore, you have to obsolete old stuff if you want there to be > only One Obvious Way To Do It. I'm totally in favor of obsoletion and removal of old cruft from the standard library. I'm totally against *not* having a standard library. Giovanni Bajo _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com