Element, XMLParser and TreeBuilder are types in ElementTree, but factory functions in _elementtree. The latter should be modified to be consistent with the former.

Note that Element is also a factory function in lxml.etree, and people have
been living with this quite happily. I don't see a reason to change either
side. There is a dedicated function iselement(obj) for exactly the purpose
of testing if something is an Element object. isinstance() is not the right
way to do it and inheritance is not portable. (the right type to inherit
from in lxml is actually called ElementBase)

I'm fine with changing the other two (XMLParser and TreeBuilder), if only
for consistency.

Stefan

In the pydev discussion once Martin raised this problem it was agreed that this is a regression in 3.3 that should be fixed, since there is code out there that relies on subclassing Element. This would make the Python and C implementations of ET more consistent, which can't be a bad thing.

For the record, the relevant mailing list discussion can be found here:

http://thread.gmane.org/gmane.comp.python.devel/129429/focus=129794

Attaching a patch that exposes ET.Element as a type, instead of as a factory function.

I'd really love to get a review for this, since I'm still relatively inexperienced when it comes to writing C extension code.

I'll go on and commit this.

The test suite of ET is not bad and all tests keep passing. Stylistic issues and best practices can be fixed later.

I want to have other work done on _elementtree, and having several patches to the same source file is very inconvenient.

New changeset ce1c26cbe5fb by Eli Bendersky in branch 'default':
Issue #14128: Exposing Element as an actual type from _elementtree, rather than a factory function.
http://hg.python.org/cpython/rev/ce1c26cbe5fb

An aside: Your commit made me realize that ET tests use monkey-patching instead of now more common idioms like using support.import_fresh_module and using subclasses to run the same tests for a Python and a C module.  There is also a doctest that is not executed.  You may want to streamline these tests.

Éric,

The tests *do* use import_fresh_module, actually. Moreover, while monkeypatching exists it's rather limited (just setting the module name for test_main).

The biggest problem with these tests is that they're based on doctest, which wasn't designed to be too flexible for this purpose. All new tests I'm adding use the unittest infrastructure in a saner way. Rewriting all existing tests from doctest to unittest, while a worthy goal, would be probably too time consuming at this point.

If you have any specific suggestions for improvement, please open a separate issue.

The TreeBuilder constructor in _elemettree doesn't accept arguments, contrary to the documentation. Added a (currently marked as failing) test.

Done with the recent completion of #14007