Repository navigation
Emit ResourceWarning when GzipFile is deleted with unwritten data #130806
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Mar 3, 2025 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Mar 4, 2025 - added a commit that references this issue
on Mar 6, 2025 Working on getting BufferedWriter warning to work, having a hard time as it involves adding a
tp_finalize, and that interacts with the existingtp_deallocwhich calls_dealloc_warnon itself and the underlyingraw(often FileIO), which is how the FileIO close warning is emitted currently. I got it working well for_pyiobut not sure how to get everything to fit for_io.Buffered{Writer,Random}. What I currently have. At the moment struggling to figure out whats the right tweaks, particularly for tests which seem to have often evolved separately from the original need, and this changes behavior (ex. _pyio tests using _io by accident, checks for no warning and unraisable exceptions, etc). Wondering if with tp_finalize as it currently works could replace the existing _dealloc_warn / FileIO system with a simpler one...While working on that, found the docs around
tp_finalizepointed to the deprecated C APIs PyErr_Fetch + PyErr_Restore, made an issue + PR to update to PyErr_GetRaisedException and PyErr_SetRaisedException: gh-131117cc: @vstinner
- changed the title
[-]Emit ResourceWarning when GzipFile or BufferedWriter are deleted with unwritten data[/-][+]Emit ResourceWarning when GzipFile is deleted with unwritten data[/+]on Mar 20, 2025 Reducing the issue to just
GzipFile, after a couple attempts at getting BufferedWriter working, have yet to find a reliable way. Is really neat how_dealloc_warnworks with thetp_finalizeinIOBase.
Feature or enhancement
Proposal:
This may indicate accidental data loss.
Ways to make sure all data is written:
BufferedIOBase,BufferedWriter, andGzipFileall support this..close()is called in both exception and regular cases..close()is always called which flushes data before closing..detach()Since 3.12 flushing has been necessary in GzipFile (see gh-105808 which was a release blocker), this makes that more visible. Users have been encountering as they upgrade to 3.12 (ex. gh-129726).
There are a number of cases of unclosed file-like objects being deleted in CPython libraries and the test suite. This issue includes resolving those cases where the new ResourceWarning is emitted.
cc: @vstinner
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#129726 (comment)
Linked PRs