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:12:20
SpamBayes Score 1.0807355e-11
Marked as misclassified No
Message-id <1328890342.05.0.718645565166.issue13988@psf.upfronthosting.co.za>
In-reply-to
Content
> If possible I would avoid pyElementTree,

I suppose it's possible, but I'm genuinely interested in a technical reason for doing so. The approach suggested in PEP 399 is useful for module in which part of the functionality is implemented in C, and then augmented in Python. ElementTree is different - it's pretty much two separate implementations of the same API.

So, I think there's little question in terms of simplicity and clarity. Having pyElementTree and cElementTree (keeping it for backwards compat), and a facade named ElementTree that chooses between them is simple, clean and intuitive.

From a performance point of view, consider the (by far) common case - where _elementtree *is* successfully imported. 

Option 1: from _elementtree import *, at the end of the Python implementation in ElementTree.py - so for each invocation, the whole import of the Python code has to be done, just to reach the overriding import * at the end.

Option 2: ElementTree is a facade that attempts to import _elementtree first. So the Python implementation in pyElementTree doesn't even have to be parsed and imported
History
Date User Action Args
2012-02-10 16:12:22eli.benderskysetrecipients: + eli.bendersky, effbot, scoder, ezio.melotti, flox
2012-02-10 16:12:22eli.benderskysetmessageid: <1328890342.05.0.718645565166.issue13988@psf.upfronthosting.co.za>
2012-02-10 16:12:20eli.benderskylinkissue13988 messages
2012-02-10 16:12:20eli.benderskycreate