gh-81954: Warn when ZipFile is closed with unwritten data - #152354
gh-81954: Warn when ZipFile is closed with unwritten data#152354cmaloney wants to merge 8 commits into
Conversation
Bring `zipfile.ZipFile` into alignment with other buffered file writers like `GzipFile` and `TextIOWrapper` by emitting a `ResourceWarning` if there is unwritten data and it is closed implicitly. ZipFile should be closed either by using it as a context manager or explicitly calling `.close()`.
Documentation build overview
160 files changed ·
|
| # records. GC cleanup order is non-deterministic and can result in data | ||
| # loss. | ||
| if (self.fp is not None and self.mode in ('w', 'x', 'a') | ||
| and self._didModify): |
There was a problem hiding this comment.
Why this complex logic? open() logs a ResourceWarning even for files open in read-mode. A ZipFile contains a file, so it should emit a ResourceWarning if it's not closed, even if it's open in read-mode, or even if all data is flushed.
There was a problem hiding this comment.
Reducing noisy cases that need to be updated for minimal value in an upgrade to 3.16. This parallels the GzipFile logic from gh-130806:
Lines 469 to 475 in 48cc257
Dropped the self._didModify part (anything opened in writable mode should be reliably closed). The self.fp is not None is how ZipFile checks "has this been closed".
3 participants
Bring
zipfile.ZipFileinto alignment with other buffered file writers likeGzipFileandTextIOWrapperby emitting aResourceWarningif there is unwritten data and it is closed implicitly.ZipFile should be closed either by using it as a context manager or explicitly calling
.close().cc: @jaraco the
_path/test_pathfixtures have quite a few ZipFiles they don't close. For now I just blanket silenced, not sure your preferred upstream fix.