Issue 33546: asyncio.Condition should become awaitable in 3.9 (original) (raw)

Issue33546

Created on 2018-05-16 18:25 by fried, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg316848 - (view) Author: Jason Fried (fried) * Date: 2018-05-16 18:25
In 3.9 we can remove the deprecated pattern for accepting __enter__ and __exit__ for locks. This will free up __await__ for Condition to use for replacing .wait() which is wart from before awaitables. My new proposed behavior is await cond which would be equivalent of: async with cond: await cond.wait()
msg317223 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-05-21 09:29
No, condition variables don't work this way. The proper code looks like: async with cond: while not : await cond.wait() It cannot be collapsed to just `await cond`.
msg317434 - (view) Author: Ɓukasz Langa (lukasz.langa) * (Python committer) Date: 2018-05-23 18:32
Andrew is right because a Condition *is* a lock. The confusing thing about this construct is that the actual logic "condition" that we're waiting for is external. It can be controlled by another coroutine that will just let us know by calling `cond.notify()` when the condition is met. On the receiver side it looks like this: async with cond: # in this block you hold the lock await cond.wait() # (this temporarily releases the lock as long as it waits) print("Another coroutine called .notify(). I hold the lock now!") It can also be used like Andrew demonstrated above, where *we* run the logic "condition" check ourselves and that check *also* requires a lock to be correct: async with cond: # in this block you hold the lock while not condition_check_with_lock(): # <- this is the actual "condition" check await cond.wait() # (temporarily releases the lock while it waits) print("Check passed and I'm holding the lock now!") Personally I find the latter example confusing because it doesn't require another coroutine to ever `.notify()` us if the initial `condition_check_with_lock()` returned True, but it *does* require another coroutine to `.notify()` us if that initial check returned False.
History
Date User Action Args
2022-04-11 14:59:00 admin set github: 77727
2018-05-23 18:32:12 lukasz.langa set messages: +
2018-05-21 09:29:32 asvetlov set status: open -> closedresolution: rejectedmessages: + stage: resolved
2018-05-16 18:25:47 fried create