[Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky eliben at gmail.com
Wed Feb 8 05:46:46 CET 2012


On Wed, Feb 8, 2012 at 06:41, Fred Drake <fdrake at acm.org> wrote:
> On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky <eliben at gmail.com> wrote:
>> Besides, in http://mail.python.org/pipermail/python-dev/2011-December/114812.html
>> Stefan Behnel said "[...] Today, ET is *only* being maintained in the
>> stdlib by Florent Xicluna [...]". Is this not true?
>
> I don't know.  I took this to be an observation rather than a declaration
> of intent by the package owner (Fredrik Lundh).
>
>> P.S. Would declaring that xml.etree is now independently maintained by
>> pydev be a bad thing? Why?
>
> So long as Fredrik owns the package, I think forking it for the standard
> library would be a bad thing, though not for technical reasons.  Fredrik
> provided his libraries for the standard library in good faith, and we still
> list him as the external maintainer.  Until *that* changes, forking would
> be inappropriate.  I'd much rather see a discussion with Fredrik about the
> future maintenance plan for ElementTree and cElementTree.
>

Yes, I realize this is a loaded issue and I agree that all steps in
this direction should be taken with Fredrik's agreement.

However, to re-focus: The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default. Will that somehow harm Fredrik's
sovereignty over ET? Are there any other problems hidden here? Because
if not, it appears like a change of only a few lines of code could
provide a significantly better XML processing experience in 3.3 for a
lot of users (and save some keystrokes for the ones who already know
to look for cElementTree).

Eli


More information about the Python-Dev mailing list