[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Stefan Behnel]

"Martin v. Löwis", 10.02.2012 10:37:
>> Given that it was two months ago that I started the "Fixing the XML
>> batteries" thread (and years since I brought up the topic for the first
>> time), it seems to be hard enough already to get anyone on python-dev
>> actually do something for Python's XML support, instead of just actively
>> discouraging those who invest time and work into it.
> 
> It depends on the nature of the changes you want to see done. Just
> bashing some piece of code is not something that I personally consider
> a worthwhile thing, so I'll likely continue to discourage changes in
> a direction that demeans some XML library in favor of some other.

This is getting off-topic for this thread, but anyway. What I meant with my
paragraph above was that none of the topics I brought up has received any
action on the side of those with commit rights yet, regardless of how
obvious they were and how much or little dispute there was about them.

IMHO, all of this boils down to whether or not we should make it easier for
users to efficiently use the stdlib. Backing ElementTree by the accelerator
module helps here, and fixing the docs to point (new) users to ElementTree
instead of MiniDOM helps as well.

I can happily accept that you have a different opinion on the latter topic
than I do. What I cannot accept is that, as we speak, this leads to users
getting drawn into using the wrong tool for their job, into wasting their
time (both for development and runtime) and potentially into getting drawn
away from the (IMHO) perfect language for XML processing.

I don't think bashing is the right word here. Everyone who, knowing the
alternatives, decides to use MiniDOM is welcome to do so. I'm just stating,
both from my personal experience and from discussions on c.l.py, that the
current documentation makes it easier for new users to take the wrong
decision for them than to make this decision in an informed way. MiniDOM
*may* be the right thing further down along the way in some cases. It's
almost *never* the right thing to start with, simply because if you do, it
inherently takes way too much time until you reach the point where the
evidence becomes obvious that it actually was the wrong decision. The
documentation should allow innocent users to see this risk clearly before
they start wasting their time.

So, getting back to the topic again, is there any reason why you would
oppose backing the ElementTree module in the stdlib by cElementTree's
accelerator module? Or can we just consider this part of the discussion
settled and start getting work done?

Stefan