This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author john.admanski
Recipients john.admanski
Date 2010-09-13.16:17:14
SpamBayes Score 1.222622e-11
Marked as misclassified No
Message-id <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-09-13 16:17:21john.admanskisetrecipients: + john.admanski
2010-09-13 16:17:20john.admanskisetmessageid: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
2010-09-13 16:17:15john.admanskilinkissue9846 messages
2010-09-13 16:17:14john.admanskicreate