RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120209/656e72ff/attachment.html below:

<div class="gmail_quote">2012/2/8 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> <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:>

> It's not frozen, it's actually maintained. 
 
</div>Indeed, it sounds like the most appropriate course (if we don't hear 
otherwise from Fredrik) may be to just update PEP 360 to acknowledge 
current reality (i.e. the most current release of ElementTree is 
actually the one maintained by Florent in the stdlib). </blockquote><div> 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> .

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

With the knowledge I acquired, I chased some other bugs related to ElementTree at the same time. With the feedback and some support coming from Antoine, Fredrik and Stefan we shaped a decent ElementTree 1.3 for the standard library.

I am not aware of any effort to maintain the ElementTree package outside of the standard library since I did this merge. So, in the current state, we could consider the standard library package as the most up to date and stable version of ElementTree.

I concur with Eli proposal to set the C accelerator as default : the test suite ensures that both implementations behave the same. 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.

However, I think it is a good thing if all the packages which are part of the standard library follow the same rules. 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.

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

description earlier in the thread may suggest, though - the test suite 
also needs to be updated to ensure that the Python version is still 
fully exercised without the C acceleration applied. And such an an 
alteration would definitely be an explicit fork, even though the user 
facing API doesn't change - we're changing the structure of the code 
in a way that means some upstream deltas (if they happen to occur) may 
not apply cleanly. </blockquote><div> 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.

-- Florent Xicluna </div></div>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4