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.ElementT
ree.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
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com
|