Author takluyver
Recipients Dhiraj_Mishra, martin.panter, mbussonn, python-dev, serhiy.storchaka, takluyver
Date 2016-02-24.14:50:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1456325457.36.0.931214183712.issue26039@psf.upfronthosting.co.za>
In-reply-to
Content
My initial patch would have allowed passing a readable file-like object into zipfile. I was persuaded that allowing ZipFile.open() to return a writable object was a more intuitive and flexible API.

Concurrent writes with zf.open(mode='w') should be impossible, because it only allows one open handle at a time. It still uses the lock inside _ZipWriteFile, so concurrent writes to a single handle should be serialised.

I would not recommend anyone try to do concurrent access to a single ZipFile object from multiple threads or coroutines. It's quite stateful, there is no mention of concurrency in the docs, and no tests I can see that try concurrent access. The only thing that might be safe is reading from two files inside the zip file (which shouldn't be changed by this), but I wouldn't want to guarantee even that.
History
Date User Action Args
2016-02-24 14:50:57takluyversetrecipients: + takluyver, python-dev, martin.panter, serhiy.storchaka, mbussonn, Dhiraj_Mishra
2016-02-24 14:50:57takluyversetmessageid: <1456325457.36.0.931214183712.issue26039@psf.upfronthosting.co.za>
2016-02-24 14:50:57takluyverlinkissue26039 messages
2016-02-24 14:50:57takluyvercreate