[issue14099] ZipFile.open() should not reopen the underlying file

[Stepan Kasal]

Stepan Kasal added the comment:

Re: children counting

You need to know the number of open children and whether the parent ZipFile object is still open.
As soon as both all children and the parent ZipFile are closed, the underlying fp (corresponding to the file name given initially) shall be closed as well.

The code submitted in the patch ensures that.  But other implementations are possible.

In any case, it is necessary to ensure that the children stay usable even if the parent ZipFile is closed, because of code like this:

    def datafile(self):
        with ZipFile(self.datafilezip, "r") as f:
            return f.open("data.txt")

This idiom currently works and should not be broken.

Re: seek()

The read can interfere not only with a parallel file expansion, but also with a ZipFile metadata read (user can list the contents of the zip again).  Both of these would have to be forbidden by the documentation, and, ideally, also enforced.  (As disscussed issue #16569)

OTOH, zipfile.py is already slow, because the decompression is implemented in Python as interpreted code.  I guess that the slowdown by seek() is neglectable compared to this.
Also note that we most often seek to the current position; the OS should notice that and return swiftly.

----------

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