[Python-Dev] Proposal: No more standard library additions

[Giovanni Bajo]

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