A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-December/058748.html below:

[Python-Dev] ElementTree in stdlib

[Python-Dev] ElementTree in stdlib [Python-Dev] ElementTree in stdlibFredrik Lundh fredrik at pythonware.com
Wed Dec 14 18:47:07 CET 2005
Jeremy Hylton wrote:

> On 12/14/05, M.-A. Lemburg <mal at egenix.com> wrote:
> > > we also need to figure out how to import the bundled version; should it be
> > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree
> > > (which would then fallback on the Python version if cElementTree isn't
> > > built) ?
> >
> > If the semantics are identical I'd prefer the latter approach
> > of using the faster variant if possible.
>
> That is my preference, too.

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).

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...

</F>

1) except for users that need a newer version, of course.



More information about the Python-Dev mailing list

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