Serhiy Storchaka added the comment:
Closed in favor of issue14099.
--
resolution: - rejected
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
David Wilson added the comment:
Compared to the cost of everything else ZipExtFile must do (e.g. 4kb string
concatenation in a loop, zlib), its surprising that lseek() would measurable at
all.
The attached file 'patch' is the minimal change I tested. It represents, in
terms of computation
Changes by Serhiy Storchaka storch...@gmail.com:
--
Removed message: http://bugs.python.org/msg176850
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
Removed message: http://bugs.python.org/msg176851
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
___
Serhiy Storchaka added the comment:
Seek can be very cheap. Anybody could actually measure it???
I am waiting for an updated patch for issue14099 to make benchmarks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
Jesús Cea Avión added the comment:
Seek can be very cheap. Anybody could actually measure it???
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Stepan Kasal added the comment:
I agree that reading from a file open for write should be forbidden, no matter
whether ZipFile was called with fp or a name.
Actually, it is not yet forbidden, and two of the tests in the zipfile.py test
suite do actually rely on this misfeature.
The first
Serhiy Storchaka added the comment:
Test:
http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch
file24624
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Serhiy Storchaka added the comment:
Test:
file24624/Proposed-fix-of-issue14099-second.patch
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Serhiy Storchaka added the comment:
Actually, it is not yet forbidden, and two of the tests in the zipfile.py
test suite do actually rely on this misfeature.
Indeed. I missed that.
Actually these tests work by accident, due to the fact that the contents of the
zipfile is placed in the file
Stepan Kasal added the comment:
but I'm afraid it's impossible to do without performance regression due to
seek before every read.
I agree that this is key question.
I would hope that the performance hit wouldn't be so bad, unless there are
actually two decompressions running concurrently.
New submission from Serhiy Storchaka:
If the ZipFile was created by passing in a file-like object as the first
argument to the constructor, then simultaneous reading or writing of different
file results in an non-consistent state. There is a warning about this in the
documentation. The
Jesús Cea Avión added the comment:
I am -0 to this. We can't prevent programmers for shotting in the foot.
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
___
Serhiy Storchaka added the comment:
Reading from closed ZipFile or reading from ZipFile opened for write already
forbidden. This is a preventing of the same kind.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16569
15 matches
Mail list logo