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 <rep...@bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
