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

Florent florent.xicluna at gmail.com
Thu Feb 9 19:49:16 CET 2012

2012/2/8 Nick Coghlan <ncoghlan at gmail.com>

On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:> > It's not frozen, it's actually maintained.

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

Actually, it was part of my learning curve to the development of Python, as you can see on the thread of the issue http://bugs.python.org/issue6472 . 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.

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.

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120209/656e72ff/attachment.html>

More information about the Python-Dev mailing list