Skip to content

Fix misleading hint for iterparse #93618

Closed

Description

@Prometheus3375

Documentation

From docs:

Because it’s so flexible, XMLPullParser can be inconvenient to use for simpler use-cases. 
If you don’t mind your application blocking on reading XML data 
but would still like to have incremental parsing capabilities, take a look at iterparse(). 
It can be useful when you’re reading a large XML document and don’t want to hold it wholly in memory.

The last sentence is wrong. iterparse eventually loads the entire file to the memory, because iterparse forms XML tree incrementally, i.e., the problem of huge memory consumption cannot be solved by using iterparse without some extra code. If a person wants to process a large file with small memory cost, then they must at least repeatedly clean root element from children (it depends on XML structure). Therefore, I suggest to remove the last sentence in docs.


The code below deletes a root child once it is completed, then processes and removes it from the memory (if nothing more references to it ofc). This allows to process 7GB XML with with a memory usage up to 10MB (in case of great number of root children).

parser = XMLPullParser(['start', 'end'])  # can be replaced with iterparse as well
root = None
with open(file) as f:
    for line in f:
        parser.feed(line)
        for event, obj in parser.read_events():
            match event:
                case 'start':
                    if root is None: root = obj
                case 'end':
                    if len(root) > 0 and obj == root[0]:
                        del root[0]
                        # process obj

parser.close()

Linked PRs

Activity

  1. c-viswanath commented on Jun 12, 2022

    @c-viswanath

    Hello @Prometheus3375 , I'm new to contributing in Open-Source and want to solve this doc issue as my first issue, could you please guide me through the process of doing the same?

  2. Prometheus3375 commented on Jun 12, 2022

    @Prometheus3375
    ContributorAuthor

    @c-viswanath AFAIK, the issue must be acknowledged by a contributor or a maintainer, and then you can create a PR with fixes.

  3. Prometheus3375 commented on Jun 12, 2022

    @Prometheus3375
    ContributorAuthor

    I rephrased initial comment here, now it should be more comprehensive.

  4. serhiy-storchaka commented on Sep 1, 2026

    @serhiy-storchaka
    Member

    PR #156763 replaces the misleading sentence.

    @Prometheus3375 is right: the tree is only built incrementally, it is not freed incrementally, so the whole document is eventually held in memory. Rather than only removing the sentence, the section now explains this and gives two examples for common cases: clearing large processed elements, and removing the processed children of an element which has many of them. It also mentions that a custom target of XMLParser does not build a tree at all.

    This should also answer gh-102055.

  5. LeonxLJX commented on Sep 3, 2026

    @LeonxLJX
  6. serhiy-storchaka commented on Sep 3, 2026

    @serhiy-storchaka
    Member

    @LeonxLJX Please, read the issue before posting such comments. There is already a PR, and the comment above mentions it.

    Also please avoid posting meaningless LLM generated comments.

  7. added a commit that references this issue on Sep 13, 2026
  8. added 2 commits that reference this issue on Sep 13, 2026
  9. added a commit that references this issue on Sep 14, 2026
  10. added a commit that references this issue on Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentation in the Doc dirtopic-XML

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions