[Python-Dev] ElementTree in stdlib

[Brett Cannon]

On 12/14/05, Michael Chermside <mcherm at mcherm.com> 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