On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
> > The change of backing ElementTree by cElementTree has already been > > implemented in the default branch (3.3) by Florent Xicluna with careful > > review from me and others. etree has an extensive (albeit a bit clumsy) > > set of tests which keep passing successfully after the change. > > I just noticed an incompatible change: xml.etree.ElementTree.Element > used to be a type, but is now a function. > Yes, this is a result of an incompatibility between the Python and C implementations of ElementTree. Since these have now been merged by default, one or the other had to be kept and the choice of cElementTree appeared to be sensible since this is what most people are expected to use in 2.7 and 3.2 anyway. I have an issue open for converting some function constructors into classes. Perhaps Element should also have this fate. > > > In the past couple of years Florent has been the de-facto maintainer of > > etree in the standard library, although I don't think he ever > > "committed" to keep maintaining it for years to come. Neither can I make > > this commitment, however I do declare that I will do my best to keep the > > library functional, and I also plan to work on improving its > > documentation and cleaning up some of the accumulated cruft in its > > implementation. I also have all the intentions to take the blame if > > something breaks. > > Would you mind adding yourself to > > http://docs.python.org/devguide/experts.html > Sure, I'll do that. Eli
_______________________________________________ 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
