-
-
Couldn't load subscription status.
- Fork 33.3k
Description
Feature or enhancement
Proposal:
Description
The iterparse() function in xml.etree.ElementTree has a TODO comment (line 1270) requesting that a ResourceWarning be emitted when the iterator is garbage collected without being explicitly closed:
def __del__(self):
# TODO: Emit a ResourceWarning if it was not explicitly closed.
# (When the close() method will be supported in all maintained Python versions.)
if close_source:
source.close()The close() method has been available for many years now, so this TODO can be implemented.
Problem
When iterparse() opens a file by filename (rather than accepting a pre-opened file object), it manages the file internally. If the iterator is not explicitly closed, the file handle remains open until garbage collection, which can lead to:
- File descriptor leaks
- Files remaining locked on Windows
- Resource exhaustion in long-running programs
Currently, no warning is issued to alert developers of this problem.
Proposed Solution
Implement the TODO by:
- Adding a
_closedflag to track whetherclose()has been called - Emitting a
ResourceWarningin__del__()if the iterator was not closed and had opened a file internally (close_source == True) - The warning should only apply when
iterparse()opened the file itself (filename passed), not when a file object was provided
Example
Current behavior (no warning):
import xml.etree.ElementTree as ET
# This leaks a file handle but gives no warning
context = ET.iterparse('data.xml')
next(context)
# Iterator goes out of scope without close()Expected behavior (with fix):
import xml.etree.ElementTree as ET
# This should emit ResourceWarning
context = ET.iterparse('data.xml')
next(context)
# ResourceWarning: unclosed file <_io.BufferedReader name='data.xml'>
# Proper usage (no warning):
context = ET.iterparse('data.xml')
next(context)
context.close() # Explicit closeHas this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response