Łukasz Langa added the comment:
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()`
Andrew Svetlov added the comment:
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`.
--
resolution: -> rejected
stage: -> resolved
status: open -> close
New submission from Jason Fried :
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
