[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)
Eli Bendersky eliben at gmail.com
Wed Feb 8 13:48:00 CET 2012
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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). 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.
Sure thing. I suppose similar machinery already exists for things like pickle / cPickle. I still maintain that it's a simple change :-)
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.
This is a very minimal delta, however. I think it can even be made simpler by replacing ElementTree with a facade module that either imports _elementtree or the Python ElementTree. So the delta vs. upstream would only be in file placement.
But these are two conflicting discussions - if changes were made in stdlib already that were not propagated upstream, what use is a clean delta?
Eli
- Previous message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Next message: [Python-Dev] folding cElementTree behind ElementTree in 3.3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]