This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eli.bendersky
Recipients effbot, eli.bendersky, ezio.melotti, flox, scoder
Date 2012-02-10.16:37:26
SpamBayes Score 2.8582058e-08
Marked as misclassified No
Message-id <CAF-Rda93fxa+0DyMhR40AzoX9uzV=AZJYFjtopb2GG9MtYiTDw@mail.gmail.com>
In-reply-to <1328891411.04.0.0153696831269.issue13988@psf.upfronthosting.co.za>
Content
>> From a performance point of view, consider the (by far) common case
>> - where _elementtree *is* successfully imported.
>> ... for each invocation, the whole import of the Python code has
>> to be done, just to reach the overriding import * at the end.
>
> This point is wrong... the _elementtree.c accelerator imports Python ElementTree already.
>
> As you can see on lines 2938 to 2945, the change could lead to an import cycle:
> http://hg.python.org/cpython/file/705b56512287/Modules/_elementtree.c#l2938
>
> Trying to sort this out, it already gives me a headache.
> I would like to remove the Python bootstrap code from the C module and try to do it differently, in a more standard way.
>

The Python code inside _elementtree could be moved to Python code,
which would then import the Python stuff it needs from pyElementTree.
Since pyElementTree doesn't import _elementtree, there will be
circular dependencies.

So this is a point *in favor* of pyElementTree being pure-Python :-)

In other words:

In xml/etree there is:

- ElementTree: tries to import cElementTree. On success, done. On
ImportError, imports pyElementTree
- pyElementTree: the pure Python implementation
- cElementTree: sets up the bootstrap Python code and tries to import
_elementtree. In case of an error, propagates an ImportError up.

Would that work?
History
Date User Action Args
2012-02-10 16:37:27eli.benderskysetrecipients: + eli.bendersky, effbot, scoder, ezio.melotti, flox
2012-02-10 16:37:26eli.benderskylinkissue13988 messages
2012-02-10 16:37:26eli.benderskycreate