New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow more low-level parser configuration in ElementTree #63682
Comments
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:
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. |
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: import sys
sys.modules['_elementtree'] = None
import xml.etree.ElementTree I'll leave this open to see what the xml experts think about the custom parser idea. |
Brecht Machiels, 03.11.2013 11:58:
This sounds like a request for a missing feature to me. Here is how lxml
Correct, although the fact that it is not prefixed with an underscore is
-1. IMHO, the underlying parser should not be made a part of the API. |
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? |
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. |
Changing subject to make it clear what this ticket is really about. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: