[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Wed Feb 8 08:03:11 CET 2012

Eli Bendersky, 08.02.2012 07:07:

On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote:

On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote:

The initial proposal of changing *the stdlib import facade* for xml.etree.ElementTree to use the C accelerator (elementtree) by default.

I guess this is one source of confusion: what are you referring to an an "import façade"? When I look in Lib/xml/etree/, I see the ElementTree, ElementPath, and ElementInclude modules, and a wrapper for cElementTree's extension module. There isn't any sort of façade for ElementTree; are you proposing to add one, perhaps in xml.etree/init.py? AFAICS ElementPath is a helper used by ElementTree, and cElementTree has one of its own. It's not documented for stand-alone use. ElementInclude also isn't documented and doesn't appear to be used anywhere. The facade can be added to xml/etree/ElementTree.py since that's the only documented module. It can attempt to do: from elementtree import * (which is what cElementTree.py) does, and on failure, just go on doing what it does now.

Basically, cElementTree (actually the accelerator module) reuses everything from ElementTree that it does not implement itself, e.g. the serialiser or the ElementPath implementation in ElementPath.py (which is not commonly being used by itself anyway).

ElementInclude is meant to be independently imported by user code and works with both implementations, although it uses plain ElementTree by default and currently needs explicit configuring for cElementTree. It looks like that need would vanish when ElementTree uses the accelerator module internally.

So, ElementTree.py is a superset of cElementTree's C module, and importing that C module into ElementTree.py instead of only importing it into cElementTree.py would just make ElementTree.py faster, that's basically it.

Stefan

More information about the Python-Dev mailing list