[Python-Dev] folding cElementTree behind ElementTree in 3.3

[Stefan Behnel]

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