[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)

Xavier Morel python-dev at masklinn.net
Mon Feb 20 12:43:50 CET 2012

On 2012-02-20, at 12:36 , Eli Bendersky wrote:

On Mon, Feb 20, 2012 at 01:12, "Martin v. Löwis" <martin at 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).

More information about the Python-Dev mailing list