Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-93618: Document the memory usage of the incremental parsers #156763

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.

Sign up for GitHub

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

Merged
serhiy-storchaka merged 1 commit into from
Sep 13, 2026
+35 −2
Merged

gh-93618: Document the memory usage of the incremental parsers #156763

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 35 additions & 2 deletions Doc/library/xml.etree.elementtree.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,8 +160,37 @@ some storage device. In such cases, blocking reads are unacceptable.
Because it's so flexible, :class:`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 :func:`iterparse`. It can be useful when you're reading a large XML document
and don't want to hold it wholly in memory.
at :func:`iterparse`.

Note that both parsers build the tree incrementally: it is not freed
incrementally, so every parsed element is kept until the whole document is
read. To keep the memory usage low, get rid of the data which is not needed
any more.

If the processed elements are large, it is enough to clear them.
This works wherever they are in the tree,
but the emptied elements are left in it::

for event, elem in ET.iterparse(source):
if elem.tag == 'record':
process(elem)
elem.clear()

If an element has a large number of children,
remove the processed children from it::

for event, elem in ET.iterparse(source, events=('start', 'end')):
if event == 'start' and elem.tag == 'parent':
parent = elem
elif event == 'end' and elem.tag == 'child':
process(elem)
parent.remove(elem)

These examples are not universal,
they only give an idea for two common cases.
If you do not need a tree at all,
parse with :class:`XMLParser` and a custom target instead;
it is not built then, and nothing has to be removed.

Where *immediate* feedback through events is wanted, calling method
:meth:`XMLPullParser.flush` can help reduce delay;
Expand Down Expand Up @@ -635,6 +664,10 @@ Functions
for applications where blocking reads can't be made. For fully non-blocking
parsing, see :class:`XMLPullParser`.

The tree is only built incrementally, it is not freed incrementally:
every parsed element is kept until the whole document is read.
See :ref:`elementtree-pull-parsing` for how to keep the memory usage low.

.. note::

:func:`iterparse` only guarantees that it has seen the ">" character of a
Expand Down
Loading