Mike Brown writes:
[ElementTree was accepted into stdlib immediately without discussion
on XML-Sig. Seems like a lack of due process.]
> Some authors of other libs may not even be aware that they could so
> easily have their code whisked into stdlib, if it's solid enough.
It's not the solidity of the CODE in ElementTree that secured the
approval. It's not even the pythonicness of the API (although that's
ElementTree's greatest strength). No, the reason for the rapid
acceptance was the solidity of the *community support*. For a long
time, lots of people (users, not just core developers) have been
thinking to themselves "why isn't ElementTree the standard Python
API for XML?". Once it was stated out loud (on c.l.py) and it was
clear that /F supported the idea, there was little to discuss.
Frankly, if at any time in the past several years the XML-SIG had
published their consensus report on the "preferred API for XML"
(or perhaps "preferred small set of APIs, each tuned for a specific
purpose"), I expect it would have been incorporated in the core.
This could have been done long before /F ever wrote ElementTree.
But historically, this isn't what happened.
I look at some other areas and find that Python tends to have one
good (hopefully excellent) implementation of a given feature, and
perhaps a few high-powered 3rd party implementations for special
purposes. For instance, there's the datetime module which satisfies
most users, then there are tools like mxDateTime for specialists.
Most users of high-precision numbers make due with the built-in
long type, but specialists use GMPY. Most users of threading find
that the threading module is sufficient, but those who really
want full co-routines get stackless.
Expressed in this fashion, I have always felt that the XML-SIG was
basically working on developing and standardizing the specialist
tools for XML, with special attention paid to things like very
high performance, very complete implementation of XML features,
cross-language standardization, automatic object serialization,
and other such features far removed from the basic "I want to read
this file and it's in XML." Those are great areas, and there are
people who need them (for some projects, I'm one of those people).
However, ElementTree is one of the few libraries that have struck
me as being canidates for the "one good implementation" that
serves the basic needs of the typical user.
-- Michael Chermside
_______________________________________________
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
