Message260808
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. |
|
Date |
User |
Action |
Args |
2016-02-24 14:50:57 | takluyver | set | recipients:
+ takluyver, python-dev, martin.panter, serhiy.storchaka, mbussonn, Dhiraj_Mishra |
2016-02-24 14:50:57 | takluyver | set | messageid: <1456325457.36.0.931214183712.issue26039@psf.upfronthosting.co.za> |
2016-02-24 14:50:57 | takluyver | link | issue26039 messages |
2016-02-24 14:50:57 | takluyver | create | |
|