eryksun added the comment:
The changeset from 03 Dec is in the Windows 2.7.9 release.
Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit
(AMD64)] on win32
Type help, copyright, credits or license for more
information.
import zipfile
zipfile._SharedFile
Roundup Robot added the comment:
New changeset 4f96e9a8eee8 by Serhiy Storchaka in branch 'default':
Don't seek to the start of the file when open ZipFile with the 'w' mode
https://hg.python.org/cpython/rev/4f96e9a8eee8
--
___
Python tracker
Roundup Robot added the comment:
New changeset ae42c4576438 by Serhiy Storchaka in branch '2.7':
Issue #14099: Backout changeset c2c4cde55f6f (except adapted tests).
https://hg.python.org/cpython/rev/ae42c4576438
New changeset 680b47c96e08 by Serhiy Storchaka in branch '3.4':
Issue #14099:
Serhiy Storchaka added the comment:
Sorry Stepan and David, but for this feature you need wait 3.5.
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
Thank you for your report Matt.
There is other problem. It is nowhere documented and newer granted and newer
mentioned when ZipFile.open() was added, but file-like objects returned by
ZipFile.open() could be read in different threads simultaneously. It
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: -Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Serhiy Storchaka added the comment:
Adding locks almost not affects performance, because reads are done by relative
large chunks and locking overhead is small.
--
Added file: http://bugs.python.org/file37733/zipfile_threadsafe.patch
___
Python
Serhiy Storchaka added the comment:
See also issue23252.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Python-bugs-list mailing
Changes by Augie Fackler li...@durin42.com:
--
nosy: +durin42
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Python-bugs-list mailing
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: fixed -
stage: resolved -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
Matt Mackall added the comment:
The committed fix breaks Mercurial.
http://bz.selenic.com/show_bug.cgi?id=4492
The underlying file-like object in our case is a wsgirequest but anything
else trying to serve a dynamically-generated zip file on the web will probably
die. We wrapped wsgirequest
Benjamin Peterson added the comment:
Okay for 2.7.10.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Python-bugs-list mailing list
David Wilson added the comment:
Could we also make a small tweak to zipfile.rst indicating the new behaviour? I
had made an initial attempt in my patch but wasn't particularly happy with the
wording.
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
How about just Objects returned by :meth:`.open` can operate independently of
the ZipFile.?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
David Wilson added the comment:
Sounds great :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset c2c4cde55f6f by Serhiy Storchaka in branch '2.7':
Issue #14099: ZipFile.open() no longer reopen the underlying file. Objects
https://hg.python.org/cpython/rev/c2c4cde55f6f
New changeset e5bb3044402b by Serhiy Storchaka in branch '3.4':
Issue
Serhiy Storchaka added the comment:
Thanks Stepan for the idea.
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
Serhiy Storchaka added the comment:
What your thoughts Benjamin? Should this patch be applied to 2.7.10 (this is
not critical for 2.7.9)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
Serhiy Storchaka added the comment:
I hesitate about applying the patch to maintained releases. On one hand,
besides interface (even non-documented details) left the same, the patch
changes interiors too much for ordinal bug. I don't see how it can break
something, but this doesn't guarantee
David Wilson added the comment:
While in spirit this is a bug fix, it's reasonably complex and affects a
popular module -- I'm not sure it should be applied to 2.x, and probably not in
a minor release of 3.x either. Would it make sense to include as part of 3.5?
(That said, I'd love to see
Serhiy Storchaka added the comment:
Thank you David for your benchmarks and patch. There are several backward
compatibility issues with the reading from ZipFile opened for write and from
closed ZipFile. This behavior is mostly undocumented (except the reading from
closed ZipFile), but even
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file37198/bench_zip.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
David Wilson added the comment:
Hi Serhiy,
Thanks for the new patch, it looks better than my attempt. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
David Wilson added the comment:
Per my comment on issue16569, the overhead of performing one seek before each
(raw file data) read is quite minimal. I have attached a new (but incomplete)
patch, on which the following microbenchmarks are based. The patch is
essentially identical to Stepan's
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
___
Serhiy Storchaka added the comment:
This issue looks as a duplicate or a superseder of issue10631. See also
issue16569.
seek() for every read should significantly decrease performance. It may be
worth to prohibit the simultaneous reading of different files from the archive.
In any case the
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
Serhiy Storchaka added the comment:
I think some benchmarks will needed to see how it will affect the performance.
Please update your patch to current sources. The module code was changed last
months.
--
___
Python tracker rep...@bugs.python.org
Stepan Kasal added the comment:
I'm not sure when I'll get to this, sorry.
Hopefully sometime soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
Serhiy Storchaka added the comment:
This idiom currently works and should not be broken.
Hmm. This seems doubtful to me, but if it is used, then I agree, it shouldn't
be broken.
I guess that the slowdown by seek() is neglectable compared to this.
Even one function call can have effect on
Serhiy Storchaka added the comment:
Sorry, not issue16304, but issue16034. The commit messages were wrong.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14099
___
Stepan Kasal ka...@ucw.cz added the comment:
Attached please find a second iteration of the fix.
This time the signature of ZipExtFile is kept backward compatible, with one new
parameter added.
--
Added file:
http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch
Éric Araujo mer...@netwok.org added the comment:
Thanks for the report and patch. I’m afraid changing the constructor signature
is not an option, due to our backward compatibility policy. Do you think the
bug can be fixed without changing the signature, or with new arguments added
after the
33 matches
Mail list logo
