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 pitrou
Recipients docs@python, neologix, pitrou, r.david.murray, tim.peters
Date 2011-11-29.20:55:53
SpamBayes Score 2.5979534e-06
Marked as misclassified No
Message-id <1322600154.01.0.466604364798.issue13502@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, so digging a bit, the feature dates back to issue1674032. 
Interestingly, the OP in that issue had already envisioned that race condition and had precisely proposed the feature to avoid it: “Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out”.

So I'm changing my mind and saying it seems desireable to return True if the wait succeeded before the timeout's end, even though the flag may have been reset in the meantime.
In 3.2, Condition.wait also returns a boolean, meaning the check in Event.wait can be atomic.
History
Date User Action Args
2011-11-29 20:55:54pitrousetrecipients: + pitrou, tim.peters, r.david.murray, neologix, docs@python
2011-11-29 20:55:54pitrousetmessageid: <1322600154.01.0.466604364798.issue13502@psf.upfronthosting.co.za>
2011-11-29 20:55:53pitroulinkissue13502 messages
2011-11-29 20:55:53pitroucreate