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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4