GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-81954: Warn when ZipFile is closed with unwritten data by cmaloney · Pull Request #152354 · python/cpython Conversation
|
Documentation build overview
160 files changed ·
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| # 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.
The reason will be displayed to describe this comment to others. Learn more.
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.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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
| def __del__(self): | |
| if self.mode == WRITE and not self.closed: | |
| import warnings | |
| warnings.warn("unclosed GzipFile", | |
| ResourceWarning, source=self, stacklevel=2) | |
| super().__del__() |
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".
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I would prefer to always emit a ResourceWarning if the zipfile is not closed explicitly. Copying gzip behavior sounds like a reasonable option here. So I'm fine with only emitting a warning if the zipfile is open in write mode.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
I tried the original reproducer: #81954 (comment) Sadly, the warnings module failed to be imported. I tried to move "lazy import warnings" to It works as expected if the zipfile object creation is moved into foo() function. Well, IMO it's fine to leave the code as it is. We cannot do better, we want to import warnings lazily and it doesn't work anymore during Python shutdown. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Oh, I noticed that there are "import warnings" in functions which are no longer needed since "lazy import warnings" was added. I wrote PR gh-155326 to remove these lines. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I noticed the now removable lazy imports as well when making this PR but felt like a sufficiently independent change that shouldn't do in the same commit. Thanks for doing the followup! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…on#152354) 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()`.
CPython now emits a ResourceWarning when a writable ZipFile is closed implicitly (python/cpython#152354).
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.