/F writes: > it's cStringIO vs. StringIO and cPickle vs. pickle situation again; the > modules are 99% compatible, but there's always someone that relies > on that last % (which is a result of ET being written in Python). Yes! > at this point, I think it's more important to guarantee that changing > "elementtree" to "xml.etree" will always work under Python 2.5 [1], > than to have a new set of potential subtle incompatibility issues. but > I have changed my mind before... Consider changing it again. I fear that if ElementTree is part of the core without cElementTree, then a meme will spread which says (and PLEASE don't quote this!) "ElementTree has a great API, but it's just too slow for real work." We already know that Python is particularly susceptable to "too slow" memes, even invalid ones. I think the best all-around solution is to include cElementTree and use it wherever possible unless the user specially imports the pure-python version. Perhaps importing "xml.etree" gets you cElementTree unless that isn't compiled on your platform, but you can import "xml.pure_python.etree" or something like that to get the pure Python version if you really want it. -- Michael Chermside
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