gh-68475: Keep comments and processing instructions outside the root element - #157434
Open
serhiy-storchaka wants to merge 8 commits into
Open
gh-68475: Keep comments and processing instructions outside the root element#157434serhiy-storchaka wants to merge 8 commits into
serhiy-storchaka wants to merge 8 commits into
Conversation
… root element ElementTree gets the children attribute, a view of the children of the document, containing the root element and any number of comments and processing instructions around it. Adding a second element is an error. iter() iterates over all of them, but find(), findall() and iterfind() still search from the root element. TreeBuilder collects the comments and processing instructions which occur outside the root element and returns them, together with the root element, from the new document() method. This only happens when insert_comments or insert_pis is set, so nothing changes for existing code. parse() asks the target for the document before close(), which releases it. The C accelerator implements document() too, so that the feature works at full parsing speed.
Registering the implementation with a cast is a call through a pointer to an incorrect function type: it is warned about by the compiler, reported by UBSan, and traps on WASI.
The name of the method which ElementTree.parse() looks up on the parser target should not clash with an attribute of a custom target.
…ment-children # Conflicts: # Modules/clinic/_elementtree.c.h
…ment-children # Conflicts: # Modules/_elementtree.c
…nt_children() TreeBuilder is unchanged: it discards comments and processing instructions outside of the root element, and close() returns the root element. The new DocumentBuilder subclass keeps them (when insert_comments or insert_pis is true) and returns the list of the children of the document from close(), the only result channel of the target protocol. ElementTree.parse() loads such a list into children, XMLID() accepts it. In C, the DocumentBuilder type shares the TreeBuilder struct and handlers; the document list is NULL for a plain TreeBuilder. The parser calls the handlers directly for both exact types.
Documentation build overview
|
Member
Author
|
@scoder, this is the alternative to #156719 after your objection to adding a method to the target protocol.
The document type declaration will be a separate PR on top of this one: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Comments and processing instructions outside of the root element were lost: the parser reported them to the target, but TreeBuilder had nowhere to put them, and ElementTree could not serialize them.
ElementTreegets thechildrenattribute, a sequence of the children of the document: the root element and the comments and processing instructions around it. It can be modified like a list, with the restriction that there is at most one element (the root).ElementTree.write()serializes all children,ElementTree.iter()iterates over all of them,find*()still search from the root.DocumentBuilderparser target is aTreeBuilderwhich keeps comments and PIs outside of the root element (wheninsert_commentsorinsert_pisis true) and returns the list of the children of the document fromclose().ElementTree.parse()andparse()load such a list intochildren;XMLID()accepts it.TreeBuilderis not changed: it still discards what is outside of the root element, andclose()still returns the root element. The result of the target reaches the caller only throughclose(), as inXMLParserand lxml (see the discussion in Remove root attribute from XMLPullParser #63190).DocumentBuilderis implemented in C too, sharing theTreeBuilderimplementation; the parser calls the handlers directly for both exact types.The document type declaration is left for a separate PR.
This is an alternative to #156719, which added
get_document_children()toTreeBuilder.