<br><br><div class="gmail_quote">2012/2/8 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:><br>
> It's not frozen, it's actually maintained.<br>
<br>
</div>Indeed, it sounds like the most appropriate course (if we don't hear<br>
otherwise from Fredrik) may be to just update PEP 360 to acknowledge<br>
current reality (i.e. the most current release of ElementTree is<br>
actually the one maintained by Florent in the stdlib).<br></blockquote><div><br>Actually, it was part of my learning curve to the development of Python, as you can see on the thread of the issue <a href="http://bugs.python.org/issue6472">http://bugs.python.org/issue6472</a> .<br>
I spent some time between December 2009 and March 2010 to merge the "experimental" 1.3 in the standard library, both for 2.7 and 3.2.<br>Upstream, there were 2 different test suites for the Python and the C implementation, but I merged them in a single test suite, and I've patched the C accelerator to conform to the same behaviour as the Python reference module.<br>
With the knowledge I acquired, I chased some other bugs related to ElementTree at the same time.<br>With the feedback and some support coming from Antoine, Fredrik and Stefan we shaped a decent ElementTree 1.3 for the standard library.<br>
<br>I am not aware of any effort to maintain the ElementTree package outside of the standard library since I did this merge.<br>So, in the current state, we could consider the standard library package as the most up to date and stable version of ElementTree.<br>
I concur with Eli proposal to set the C accelerator as default : the test suite ensures that both implementations behave the same.<br><br>I cannot commit myself for the long-term maintenance of ElementTree in the standard library, both because I don't have a strong interest in XML parsing, and because I have many other projects which keep me away from core python development for long period of times.<br>
<br>However, I think it is a good thing if all the packages which are part of the standard library follow the same rules.<br>We should try to find an agreement with Fredrik, explicit or implicit, which delegates the evolution and the maintenance of ElementTree to the Python community.<br>
IIRC, we have other examples in the standard library where the community support helped a lot to refresh a package where the original maintainer did not have enough time to pursue its work.<br><br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'll note that this change isn't *quite* as simple as Eli's<br>
description earlier in the thread may suggest, though - the test suite<br>
also needs to be updated to ensure that the Python version is still<br>
fully exercised without the C acceleration applied. And such an an<br>
alteration would definitely be an explicit fork, even though the user<br>
facing API doesn't change - we're changing the structure of the code<br>
in a way that means some upstream deltas (if they happen to occur) may<br>
not apply cleanly.<br><br></blockquote><div><br>The test suite is a "de facto" fork of the upstream test suites, since upstream test suites do not guarantee the same behaviour between cElementTree and ElementTree.<br>
<br><br>-- <br>Florent Xicluna<br></div></div>