Eli Bendersky <eli...@gmail.com> added the comment: > 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13988> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com