[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Xavier Morel]

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).