[New-bugs-announce] [issue9846] ZipExtFile provides no mechanism for closing the underlying file object

[John Admanski]

New submission from John Admanski <jadmanski at gmail.com>:

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.

----------
components: Library (Lib)
messages: 116322
nosy: john.admanski
priority: normal
severity: normal
status: open
title: ZipExtFile provides no mechanism for closing the underlying file object
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________