ZipExtFile provides no mechanism for closing the underlying file object #54055
Description
| BPO | 9846 |
|---|---|
| Nosy | @jcea, @pitrou, @merwok, @bitdancer, @briancurtin, @ambv |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2010-11-22.23:35:02.166>
created_at = <Date 2010-09-13.16:17:15.714>
labels = ['type-feature', 'library']
title = 'ZipExtFile provides no mechanism for closing the underlying file object'
updated_at = <Date 2012-11-04.01:33:45.455>
user = 'https://bugs.python.org/johnadmanski'bugs.python.org fields:
activity = <Date 2012-11-04.01:33:45.455>
actor = 'python-dev'
assignee = 'none'
closed = True
closed_date = <Date 2010-11-22.23:35:02.166>
closer = 'lukasz.langa'
components = ['Library (Lib)']
creation = <Date 2010-09-13.16:17:15.714>
creator = 'john.admanski'
dependencies = []
files = ['19778']
hgrepos = []
issue_num = 9846
keywords = ['patch']
message_count = 10.0
messages = ['116322', '116329', '116356', '116361', '116395', '120075', '122176', '122177', '174733', '174736']
nosy_count = 8.0
nosy_names = ['jcea', 'pitrou', 'eric.araujo', 'r.david.murray', 'brian.curtin', 'lukasz.langa', 'john.admanski', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue9846'
versions = ['Python 3.2']
Activity
johnadmanski commentedon Sep 13, 2010
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.
pitrou commentedon Sep 13, 2010
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.
johnadmanski commentedon Sep 14, 2010
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.
bitdancer commentedon Sep 14, 2010
Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method? (And document it, of course).
pitrou commentedon Sep 14, 2010
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:
briancurtin commentedon Oct 31, 2010
A fix to this would help silence a number of ResourceWarning messages coming out of the test suite.
ambv commentedon Nov 22, 2010
Adding a patch implementing the discussed functionality, removing almost all of the ResourceWarnings raised by zipfile.
ambv commentedon Nov 22, 2010
Committed in rev 86699.
jcea commentedon Nov 4, 2012
This code was not backported to python 2.7. See Issue bpo-16183
python-dev commentedon Nov 4, 2012
New changeset 6a14f692df1c by Jesus Cea in branch '2.7':
Closes bpo-16183: ZipExtFile object close without file handle closed (backporting of Issue bpo-9846)
http://hg.python.org/cpython/rev/6a14f692df1c