On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > /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. >
I don't think this will necessarily happen. You are assuming people are going to know there is a faster way than ET written in Python. I think most people consider stuff in the stdlib good and fast enough for most uses and when they want faster they roll their own. And since I have always voted on the side of "have a C version only if someone wants to maintain a C version but don't have both C and Python", I say /F should include which ever he wants, but I personally vote for only one version. So if /F is going to continue to maintain cElementTree and since it is already written I say use that and just get the speed boost and eliminate the isssue of people relying on that 1% semantic difference between the Python and C version. -Brett _______________________________________________ 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