classification
Title: ZipExtFile provides no mechanism for closing the underlying file object
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, eric.araujo, jcea, john.admanski, lukasz.langa, pitrou, python-dev, r.david.murray
Priority: normal Keywords: patch

Created on 2010-09-13 16:17 by john.admanski, last changed 2012-11-04 01:33 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
issue9846.diff lukasz.langa, 2010-11-22 23:13 ZipExtFile now can optionally close the passed in fileobj as well
Messages (10)
msg116322 - (view) Author: John Admanski (john.admanski) Date: 2010-09-13 16:17
When creating a ZipExtFile through ZipFile.open, the if the original ZipFile object was created with a filename then a new file object will be opened and given to the ZipExtFile to use for its file operations. There is no explicit mechanism that will allow you to release this file.

ZipExtFile does have an (undocumented?) close method, but this won't actually close the file object that underlies it; probably because it has no way of knowing if it actually owns the file object or if it just has a reference to a file object that belongs to the ZipFile.

You can work around this by destroying references to the ZipExtFile and letting the file's __del__ handle the close for you but this relies on implementation details of ZipExtFile.

Found in Python 3.1 but a look at svn.python.org suggests that this problem is still there in 2.7 and 3.2; however, I haven't actually tried it with them.
msg116329 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-13 17:02
Indeed. However, the ZipFile itself knows whether to close the file (self._filePassed). By adding a constructor argument to ZipExtFile and a __del__ method, it would solve the issue.
msg116356 - (view) Author: John Admanski (john.admanski) Date: 2010-09-14 00:03
I'm not sure that's much of an improvement on the existing behavior, though; as I mentioned you can already work around it by killing all the references to the ZipExtFile and the underlying file object will get automatically closed if the ZipExtFile is the only object using it, so adding an explicit __del__ that does the same thing isn't much of an improvement.

Since ZipExtFile is supposed to be a file-like object (albeit a read-only one) it would make sense to be able to release the underlying resources the same way you normally do with a file...by closing it.
msg116361 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-14 02:01
Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method?  (And document it, of course).
msg116395 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-14 12:45
> Antoine, any reason not to put the close in the ZipFileExt close method 
> instead of a __del__ method?  (And document it, of course).

You are right, a close() method would be enough.
Furthermore, ZipExtFile already supports the context manager protocol (implicitly calling BufferedIOBase.close()), so you will simply be able to write:

with myzipfile.open("README", "r") as f:
    # ...
msg120075 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-10-31 18:05
A fix to this would help silence a number of ResourceWarning messages coming out of the test suite.
msg122176 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2010-11-22 23:13
Adding a patch implementing the discussed functionality, removing almost all of the ResourceWarnings raised by zipfile.
msg122177 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2010-11-22 23:35
Committed in rev 86699.
msg174733 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2012-11-04 01:16
This code was not backported to python 2.7. See Issue #16183
msg174736 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-11-04 01:33
New changeset 6a14f692df1c by Jesus Cea in branch '2.7':
Closes #16183: ZipExtFile object close without file handle closed (backporting of Issue #9846)
http://hg.python.org/cpython/rev/6a14f692df1c
History
Date User Action Args
2012-11-04 01:33:45python-devsetnosy: + python-dev
messages: + msg174736
2012-11-04 01:16:55jceasetnosy: + jcea
messages: + msg174733
2010-11-22 23:35:02lukasz.langasetstatus: open -> closed
resolution: accepted
messages: + msg122177

stage: patch review -> resolved
2010-11-22 23:13:34lukasz.langasetfiles: + issue9846.diff

nosy: + lukasz.langa
messages: + msg122176

keywords: + patch
stage: needs patch -> patch review
2010-11-02 21:47:15eric.araujosetnosy: + eric.araujo
2010-10-31 18:05:45brian.curtinsetnosy: + brian.curtin
messages: + msg120075
2010-09-14 12:45:16pitrousetmessages: + msg116395
2010-09-14 02:01:59r.david.murraysetnosy: + r.david.murray
messages: + msg116361
2010-09-14 00:03:02john.admanskisetmessages: + msg116356
2010-09-13 17:02:19pitrousetversions: + Python 3.2, - Python 3.1
nosy: + pitrou

messages: + msg116329

stage: needs patch
2010-09-13 16:17:15john.admanskicreate