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 r.david.murray
Recipients Arfrever, Jim.Jewett, asvetlov, gregory.p.smith, gvanrossum, ncoghlan, pitrou, r.david.murray, skrah, vstinner
Date 2012-04-01.16:27:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333297625.14.0.513992446401.issue14417@psf.upfronthosting.co.za>
In-reply-to
Content
Antoine: I don't think the point of this code is to come up with a unit (or other) test for the behavior, but to try to determine empirically whether or not this error is likely to be an issue in naive production code (whether it is existing 3.x code or stuff ported from Python2). Thus the mention of "cheating" (doing things production code would not be doing). 

The answer so far appears to be "no", which is good.

Which in the context of this particular issue then raises the question of whether there is in fact any additional support beyond the normal threading lock facilities that we want to provide in the stdlib.

And the answer to that is thus probably no as well, since code likely to run into the error is also likely to need locking around the dict in question *anyway*.  

Which is what Guido's intuition was to begin with.
History
Date User Action Args
2012-04-01 16:27:05r.david.murraysetrecipients: + r.david.murray, gvanrossum, gregory.p.smith, ncoghlan, pitrou, vstinner, Arfrever, asvetlov, skrah, Jim.Jewett
2012-04-01 16:27:05r.david.murraysetmessageid: <1333297625.14.0.513992446401.issue14417@psf.upfronthosting.co.za>
2012-04-01 16:27:04r.david.murraylinkissue14417 messages
2012-04-01 16:27:04r.david.murraycreate