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.

Title: _elementtree should expose types and factory functions consistently with ElementTree
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: eli.bendersky Nosy List: Arfrever, effbot, eli.bendersky, eric.araujo, ezio.melotti, flox, python-dev, scoder
Priority: high Keywords: patch

Created on 2012-02-26 09:30 by eli.bendersky, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
Element_class_issue14128.1.patch eli.bendersky, 2012-03-02 10:22 review
Messages (11)
msg154317 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-02-26 09:30
Element, XMLParser and TreeBuilder are types in ElementTree, but factory functions in _elementtree. The latter should be modified to be consistent with the former.
msg154321 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-02-26 10:21
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.

msg154322 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-02-26 10:28
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.
msg154331 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2012-02-26 11:56
For the record, the relevant mailing list discussion can be found here:
msg154757 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-02 10:22
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.
msg154876 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-04 03:43
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.
msg154878 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-03-04 05:15
New changeset ce1c26cbe5fb by Eli Bendersky in branch 'default':
Issue #14128: Exposing Element as an actual type from _elementtree, rather than a factory function.
msg154881 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-04 08:39
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.
msg154882 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-04 08:53

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.
msg156025 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-03-16 13:45
The TreeBuilder constructor in _elemettree doesn't accept arguments, contrary to the documentation. Added a (currently marked as failing) test.
msg162061 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) Date: 2012-06-01 08:42
Done with the recent completion of #14007
Date User Action Args
2022-04-11 14:57:27adminsetgithub: 58336
2012-06-01 08:42:13eli.benderskysetstatus: open -> closed
resolution: fixed
messages: + msg162061

stage: needs patch -> resolved
2012-03-16 13:45:35eli.benderskysetmessages: + msg156025
2012-03-04 08:57:01eli.benderskysetmessages: - msg154883
2012-03-04 08:54:26eli.benderskysetmessages: + msg154883
2012-03-04 08:53:22eli.benderskysetmessages: + msg154882
2012-03-04 08:39:36eric.araujosetnosy: + eric.araujo
messages: + msg154881
2012-03-04 05:15:57python-devsetnosy: + python-dev
messages: + msg154878
2012-03-04 03:43:16eli.benderskysetmessages: + msg154876
2012-03-02 10:22:27eli.benderskysetfiles: + Element_class_issue14128.1.patch
keywords: + patch
messages: + msg154757
2012-02-26 17:52:33Arfreversetnosy: + Arfrever
2012-02-26 11:56:41scodersetmessages: + msg154331
2012-02-26 11:48:36floxsetnosy: + effbot
2012-02-26 10:28:55eli.benderskysetmessages: + msg154322
2012-02-26 10:21:31scodersetmessages: + msg154321
2012-02-26 09:44:39ezio.melottisetnosy: + ezio.melotti
2012-02-26 09:30:19eli.benderskycreate