On 2012-02-20, at 12:36 , Eli Bendersky wrote: > 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.
I'm not sure that's much of an issue, Element (and most of the top-level utility "constructors") are documented as being frontend interfaces with no specific type of their own, and indeed they are simply functions in lxml, just as they are in cElementTree. Others will probably disagree, but as far as I am concerned these can stay functions, avoid issues when switching to lxml or between ElementTree and lxml (from one project to the next). _______________________________________________ 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
