[Python-Dev] Fixing the XML batteries

[Eli Bendersky]

> What should change?
>
> a) The stdlib documentation should help users to choose the right tool right
> from the start. Instead of using the totally misleading wording that it uses
> now, it should be honest about the performance characteristics of MiniDOM
> and should actively suggest that those who don't know what to choose (or
> even *that* they can choose) should not use MiniDOM in the first place. I
> created a ticket (issue11379) for a minor step in this direction, but given
> the responses, I'm rather convinced that there's a lot more that can be done
> and should be done, and that it should be done now, right for the next
> release.

On one hand I agree that ET should be emphasized since it's the better
API with a much faster implementation. But I also understand Martin's
point of view that minidom has its place, so IMHO some sort of
compromise should be reached. Perhaps we can recommend using ET for
those not specifically interested in the DOM interface, but for those
who *are*, minidom is still a good stdlib option (?).

Tying this doc clarification with an optimization in minidom is not
something that makes sense. This is just delaying a much needed change
forever.

>
> b) cElementTree should finally loose it's "special" status as a separate
> library and disappear as an accelerator module behind ElementTree. This has
> been suggested a couple of times already, and AFAIR, there was some
> opposition because 1) ET was maintained outside of the stdlib and 2) the
> APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2
> was a U-turn. Today, ET is *only* being maintained in the stdlib by Florent
> Xicluna (who is doing a good job with it), and ET 1.3 has basically made the
> APIs of both implementations compatible again. So, 3.3 would be the right
> milestone for fixing the "two libs for one" quirk.

This, at least in my view, is the more important point which
unfortunately got much less attention in the thread. I was a bit
shocked to see that in 3.3 trunk we still have both the Python and C
versions exposed and only formally document ElementTree (the Python
version), The only reference to cElementTree is an un-emphasized note:

  A C implementation of this API is available as xml.etree.cElementTree.

Is there anything that *really* blocks providing cElementTree on
"import ElementTree" and removing the explicit cElementTree for 3.3
(or at least leaving it with a deprecation warning)?

Eli