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 _______________________________________________ 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
