[Python-Dev] Fixing the XML batteries

[Terry Reedy]

On 2/6/2012 8:01 AM, Eli Bendersky wrote:

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

If you can, go ahead and write a patch saying something like that. It 
should not be hard to come up with something that is a definite 
improvement. Create a tracker issue for comment. but don't let it sit 
forever.

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

Right.

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

Since the current policy seems to be to hide C behind Python when there 
is both, I assume that finishing the transition here is something just 
not gotten around to yet. Open another issue if there is not one.

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

If cElementTree were renamed _ElementTree for import from ElementTree, 
then a new cElementTree.py could raise the warning and then import 
_ElementTree also.

-- 
Terry Jan Reedy