[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: The backported package now exists on PyPI as zipfile36. It's passing the tests on 3.4 - I haven't tested further back. I'm trying out Gitlab for hosting it: https://gitlab.com/takluyver/zipfile36 -- ___ Python

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: LGTM. Thank you Thomas. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Roundup Robot added the comment: New changeset 29b470b8ab77 by Serhiy Storchaka in branch 'default': Issue #26039: Document ZipInfo.is_dir() and make force_zip64 keyword-only. https://hg.python.org/cpython/rev/29b470b8ab77 -- ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Updated version of the patch with the detail moved to rst. -- Added file: http://bugs.python.org/file42855/zipfile-flex-bonus2.patch ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: Agreed that the docstring should be shorten version of the documentation and not vice versa. The directory slash information is implementation detail. I'm not sure it is needed in the documentation. -- ___ Python

[issue26039] More flexibility in zipfile write interface

Martin Panter added the comment: The bonus patch looks okay, although I wonder if the directory slash (/) information should be in the RST rather than doc string. Usually the RST has all the details, and doc strings are just summaries. Regarding exceptions, I can sympathise with both sides of

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Patch attached for points 2 and 3 -- Added file: http://bugs.python.org/file42851/zipfile-flex-bonus.patch ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: 1. For the cases like read/write handles conflicting, ValueError doesn't seem quite right to me - I take ValueError to mean that you have passed an invalid value to a function. RuntimeError feels like the closest fit for 'the current state does not allow this

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: There are yet few issues. 1. Currently RuntimeError is widely used in zipfile. But in most cases ValueError would be more appropriate since it programming error (for example ValueError is raised when try to read or write to closed file). See issue24693,

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: Let me know when you create a backport package Thomas. I'd like to help. -- stage: commit review -> resolved ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Thanks Serhiy! I am marking this as fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue26039] More flexibility in zipfile write interface

Roundup Robot added the comment: New changeset 175c3f1d0256 by Serhiy Storchaka in branch 'default': Issue #26039: zipfile.ZipFile.open() can now be used to write data into a ZIP https://hg.python.org/cpython/rev/175c3f1d0256 -- ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Martin Panter added the comment: Yes this looks okay to me, so go ahead. My only concern was other methods affecting the file position while in the middle of writing, but it looks like those methods maintain separate objects like self.filelist, so there is no conflict. --

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: Thank you for your contribution Thomas. I'll push the patch with fixed writestr in short time unless Martin left comments. -- stage: patch review -> commit review ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Thanks Serhiy. I'm quite happy with that set of constraints. I had a look over your patch set, and just spotted one thing in writestr that I have overlooked all along. -- ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: I have added comments for tests and documentation. The implementation looks correct. But I prefer simpler solution on this stage. Here is something between zipfile-open-w5.patch and zipfile-open-w8.patch, close to zipfile-open-w5.patch with fixed issues. *

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Ping? Once this is landed, I intend to make a backport package of it so I can start using it before Python 3.6 comes out. -- ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Changes by Марк Коренберг : -- nosy: -mmarkk ___ Python tracker ___ ___

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Any further review comments on this? -- ___ Python tracker ___ ___

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: zipfile-open-w8 removes the concurrent read-write check for non-seekable files. As Martin points out, reading currently requires seeking, and a streaming read API would look very different from the current API. -- Added file:

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: zipfile-open-w7 adds a test that Martin requested -- Added file: http://bugs.python.org/file42597/zipfile-open-w7.patch ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Martin Panter added the comment: I understand Python’s zipfile module does not allow reading unless seek() is supported (this was one of Марк’s complaints). So it is irrelevant whether we are writing. I left a few comments, but it sounds like it is valid read and write at the same time.

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: It wasn't as bad as I thought (hopefully that doesn't mean I've missed something). zipfile-open-w6.patch allows interleaved reads and writes so long as the underlying file object is seekable. You still can't have multiple write handles open (it wouldn't know

[issue26039] More flexibility in zipfile write interface

Serhiy Storchaka added the comment: test_write_after_read was added in issue14099. It doesn't test intended behavior, it tests existing behavior just in case to not change it unintentionally. It is desirable to preserve it, but if there is no simple way, may be we can change it. --

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Martin, Serhiy: Am I right that it would be unacceptable to change the test, and I therefore need to find a way to allow writestr while a reading-mode handle is open? -- ___ Python tracker

[issue26039] More flexibility in zipfile write interface

Thomas Kluyver added the comment: Sorry for the delay, this fell off my radar because emails from both the bug tracker and Rietveld tend to fall foul of my spam filters, so I have to go and check. I have implemented Serhiy's suggestions, but there turns out to be a test

[issue26039] More flexibility in zipfile write interface

Марк Коренберг added the comment: https://github.com/SpiderOak/ZipStream tries to implement streaming in one more kind. Also libarchive have experimental support of streaming write to zip archives in newest version. So problem is actual. -- ___

[issue26039] More flexibility in zipfile write interface

Martin Panter added the comment: Mark: I suggest to keep this discussion focussed on writing zip files, although I agree some enhancements to help reading without seeking could be reasonable. -- title: More flexibility in zipfile interface -> More flexibility in zipfile write