[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Stefan Behnel]

Eli Bendersky, 10.02.2012 10:06:
> On Fri, Feb 10, 2012 at 10:32, Florent wrote:
>> 2012/2/10 Eli Bendersky
>>>>
>>>
>>> Thanks for the input, Florent. So, to paraphrase, there already are
>>> code changes in the stdlib version of ET/cET which are not upstream.
>>> You made it explicit about the tests, so the question is only left for
>>> the modules themselves. Is that right?
>>>
>>
>> The port of ElementTree to Python 3000 was done in the standard
>> library only. The work was done back in 2006, 2007 and 2008.
>> There was never a public version of ElementTree for Python 3 outside
>> of the standard library.
>> It is already a significant change from the upstream branch (many
>> changes in the C extension code).
>>
>> Then when I enforced the same test suite for both implementation, I
>> have fixed many things in the C extension module too. To my knowledge,
>> these fixes were not included upstream.
>>
>> Since two years, there was regular maintenance of the package in the
>> standard library, but none of the patch were integrated upstream.
> 
> Folks, with this in mind, can we just acknowledge that the stdlib
> ElementTree is de-facto forked from Fredrik Lundh's official releases
> and get on with our lives? Note the code review discussion here -
> http://codereview.appspot.com/207048/show - where Fredrik Lundh more
> or less acknowledges this fact and shows no real objections to it.
> 
> By "get on with our lives" I mean keep fixing problems in ElementTree
> inside stdlib, as well as work on exposing the C implementation behind
> the ElementTree API by default, falling back on the Python API (and
> being true to PEP 399).

+1

None of this would make the situation any worse than it currently is, but
provide serious improvements to the user experience.

Stefan