[Python-Dev] ElementTree in stdlib

Brett Cannon bcannon at gmail.com
Wed Dec 14 22:48:35 CET 2005

On 12/14/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 01:16 PM 12/14/2005 -0800, Brett Cannon wrote:
> >On 12/14/05, Michael Chermside <mcherm at mcherm.com> wrote:
> > > 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.
> Actually, he's said that the C version should be the default, with the
> Python version only used if you have subclassing needs that can't be met by
> the C version.

Ah, misread it.

> >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.
> Having a Python version available for Jython, PyPy, etc., is a good idea;
> Michael's proposal lets us have your cake (C version be the default) and
> eat it too (have the pure Python available for other platforms and for
> explicit use by subclassers.

Good point.  My preference then would be to not directly expose it but
have it there for the other distributions to use with an added note to
make sure to not use anyt edge semantics that might crop up from the
different versions since they might be using the Python version.


More information about the Python-Dev mailing list