[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Florent]

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>