[Python-Dev] ElementTree in stdlib

["Martin v. Löwis"]

Mike Brown wrote:
> Catching up on some python-dev email, I was surprised to see that things seem 
> to be barrelling ahead with the adding of ElementTree to Python core without 
> any discussion on XML-SIG. Sidestepping XML-SIG and the proving grounds of 
> PyXML in order to satsify the demand for a Pythonic databinding+API for XML in 
> stdlib seems to be a bit of a raised middle finger to those folks who have 
> worked hard on competing or differently-scoped APIs, each of which deserves a 
> bit more peer review than just a single nomination on python-dev, which seems 
> to be all it took to obtain a blessing for ElementTree. 

That is not true. The single nomination actually triggered a (admittedly
fast) process, where multiple people spoke in favour, not just a single
one. It also followed a discussion on python-list.

> I have nothing against 
> ElementTree, and would like to see more XML processing options in core, but it 
> seems to me like the XML-SIG is being deliberately left out of this process.

I think your impression is wrong (atleast on my part): I did not
deliberately side-step xml-sig; it just didn't occur to me to have the
discussion there also. I implicitly assumed most people on xml-sig would
agree.

> Just last month, Guido submitted to XML-SIG a Pythonic XML API that he had 
> been tinkering with.[1] I don't think anyone was really bold enough to tell 
> him what they really thought of it (other than that it is a lot like XIST), 
> but it was admirable that he put it up for peer review rather than just 
> dropping it into stdlib.

Again, your impression is somewhat wrong: Guido first submitted the code
to the SF bug tracker; there I commented that he should discuss it on
xml-sig. I based this recommendation on my view that any such library
should see a wider audience first before being admitted to the core;
this library of Guido had (to my knowledge) not been seen by a wider
audience.

This is unlike ElementTree, which had existed for quite some time, and
collected a lot of community feedback.

> But the problem of how to choose from 
> the many options also became immediately apparent.[2] The discussion stalled, 
> but I think it should start up again, in the proper forum, rather than letting 
> the first-mentioned API supplant the dozen+ alternatives that could also be 
> considered as candidates.[3]

Well, this is one of the big problems with XML: there are so many
libraries to chose from, for so many different kinds of applications.
It took me some time to understand what kind of application Guido's
library is targetting - and such an analysis always ends up with
saying "It is like X, but has Y instead".

In this setting, how should we chose a library? In the last round,
it was "let's believe in standards". I personally still believe in
standards, but it appears that the Python community views them as too
bloated.

So as that has more-or-less failed, the next natural approach is
"let's believe in the community". For that, two things need to
happen: the author of the package must indicate that he would like
to see it incorporated, and the users must indicate that they like
the package. Both has happened for ElementTree, but I think it
could happen for other packages, as well.

If it is merely the lack of due process you are complaining about,
and you agree with the result, then IMO nothing would need to be
changed about the result. Discussing it post-factum on xml-sig
might still be valuable.

Regards,
Martin