This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Dhiraj_Mishra, martin.panter, mbussonn, python-dev, serhiy.storchaka, takluyver
Date 2016-02-23.21:52:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1456264333.71.0.0484289568742.issue26039@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the pointer Dhiraj. I prefer the open(mode="w") version proposed here, as being more flexible. This way you could wrap the writer object in e.g. TextIOWrapper. The other patch requires passing in a file reader object.

Having another look at zipfile-open-w4.patch, I have some thoughts about locking and the writing-while-reading restriction:

The lock seems to be designed to serialize reads and writes (which operate on the common underlying file object). See revision 4973ccd46e32, and <https://bugs.python.org/issue14099#msg234142>, although it would be good to document this, or at the minimum add a comment explaining the purpose and scope of the lock.

Currently, it appears that write() and writestr() acquire the lock, so I presume it is intended that these methods can be called multiple times concurrently, and also while the zip file is being read. With the patch, writestr() still preserves the lock usage, but write() does not because it is now implemented in terms of the new open(mode="w") method.

I think it would be good to clarify that the lock does _not_ protect concurrent writes via open(mode="w").
History
Date User Action Args
2016-02-23 21:52:13martin.pantersetrecipients: + martin.panter, python-dev, takluyver, serhiy.storchaka, mbussonn, Dhiraj_Mishra
2016-02-23 21:52:13martin.pantersetmessageid: <1456264333.71.0.0484289568742.issue26039@psf.upfronthosting.co.za>
2016-02-23 21:52:13martin.panterlinkissue26039 messages
2016-02-23 21:52:12martin.pantercreate