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.

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.

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.

Antoine, any reason not to put the close in the ZipFileExt close method instead of a __del__ method?  (And document it, of course).

> 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:
    # ...

A fix to this would help silence a number of ResourceWarning messages coming out of the test suite.

Adding a patch implementing the discussed functionality, removing almost all of the ResourceWarnings raised by zipfile.

Committed in rev 86699.

This code was not backported to python 2.7. See Issue #16183

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