/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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
