Repository navigation
Allow more low-level parser configuration in ElementTree #63682
Description
| BPO | 19483 |
|---|---|
| Nosy | @scoder, @bitdancer |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2013-11-03.10:58:40.547>
labels = ['expert-XML', 'type-bug', '3.10']
title = 'Allow more low-level parser configuration in ElementTree'
updated_at = <Date 2020-09-08.05:01:02.719>
user = 'https://bugs.python.org/brechtm'bugs.python.org fields:
activity = <Date 2020-09-08.05:01:02.719>
actor = 'scoder'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['XML']
creation = <Date 2013-11-03.10:58:40.547>
creator = 'brechtm'
dependencies = []
files = ['48904']
hgrepos = []
issue_num = 19483
keywords = []
message_count = 6.0
messages = ['202011', '202034', '202037', '202040', '202049', '376546']
nosy_count = 4.0
nosy_names = ['scoder', 'r.david.murray', 'eli.bendersky', 'brechtm']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19483'
versions = ['Python 3.10']
Activity
brechtm commentedon Nov 3, 2013
With Python 3.2, I subclassed ElementTree.XMLParser to set ExternalEntityRefHandler on the XMLParser's (expat) 'parser' member. I understand the 'parser' member is not part of the public API, but this was the only way to customize the parser without having to write a parser from scratch.
With 3.3, cElementTree replaces the Python implementation by default. Its XMLParser class has no accessible 'parser' member to configure. Unfortunately, there does not seem to be a way to use the pure-Python XMLParser, which would still allow for customization of the parser. Why is the Python version still in the library if it can't be accessed? Only for platforms where the C extension is not available?
I see two possible solutions:
Have XMLParser (both the C and Python versions) accept an optional parser argument, so that a custom parser can be passed in.
Make the Python version of ElementTree available again.
My other option is to copy the Python XMLParser version into my project. I would like to avoid this, as this would duplicate a lot of perfectly good code.
Perhaps there are other solutions?
bitdancer commentedon Nov 3, 2013
It is there so that Python implementations (other than cPython) that do not have ElementTree accelerator modules can fall back on the pure python version.
You can import the pure python version in cPython by blocking the import of the C accelerator:
I'll leave this open to see what the xml experts think about the custom parser idea.
scoder commentedon Nov 3, 2013
Brecht Machiels, 03.11.2013 11:58:
This sounds like a request for a missing feature to me. Here is how lxml
handles it:
http://lxml.de/resolvers.html
Correct, although the fact that it is not prefixed with an underscore is
rather unfortunate. IMHO, there is no guarantee that the underlying parser
will always be expat, and in fact, it is not in lxml.
-1. IMHO, the underlying parser should not be made a part of the API.
Instead, whatever features it provides that are needed on user side should
be mapped and abstracted in one way or another. Resolving external entity
references is something that should not be done as low-level as expat.
brechtm commentedon Nov 3, 2013
This will not work if xml.etree.ElementTree was already imported by another module, I think. Of course, you can take care of that case, but it doesn't get any prettier (I have done this for now).
Any objections to making the pure Python versions available under a different name?
bitdancer commentedon Nov 3, 2013
Yes, you have to do the sys.modules set at the start of your application.
The python module is what gets imported, it is just that the C classes override some of the classes from the Python module when they are imported. So no, there's no way to make the pure python available in cPython other than blocking the _elementtree import at application startup.
If you want to discuss changing this fact, it would be a broader discussion in the context of PEP-399, and should take place on the python-dev mailing list.
scoder commentedon Sep 8, 2020
Changing subject to make it clear what this ticket is really about.
[-]Pure-Python ElementTree classes no longer available since 3.3[/-][+]Allow more low-level parser configuration in ElementTree[/+]