The explanation

"Conditions are used to signal that a resource is available. Whomever was waiting for the condition, can use that resource until they are done with it."

from Martijn Pieters' answer is a bit wrong and misleading (granted similarly so as in the linked threading-related question). Conditions are more concerned with halting execution, when the resource is not in a proper state (giving access back to other tasks, i.e. making the lock conditional) and grouping tasks into sets, that should be awakened together in case of certain events.

The "async for"-block using the condition as the context manager (or rather the embedded lock) actually already ensures exclusive access to the shared resource throughout the block (via implicit require/release-calls). We are supposed to use the condition here as shown in Martijn's Python-example or the Python documentation, but really the embedded lock gets used for this, which makes more sense as it provides or represents the mutually excl. access functionality for the resource. Also we can use various conditions based on the same underlying lock within this block, so the block is not bound to a certain condition, but rather a certain lock/shared resource.

If we only need the excl. access though, when some condition is met, then we might want to free the resource and suspend ourselves until that condition/event occurs again. So conditions are certain states or events in regards to the shared resource, that are necessary for us to proceed with our operations on that resource.

E.g. we can only proceed with adding a value to a shared queue, when there is space left in the underlying buffer. So when the queue is full we wait for a condition called "notFull", that gets controlled/triggered by the code taking values off the queue.

See this BoundedBuffer/Queue example in Java making good use of Conditions for that use case.

It is very comparable to how Conditions work in Python, but it showcases how the common lock is used to create the critical sections and how multiple conditions can be used within those. We don't even need to wait for a condition, when we notice ourselves, that the condition is already met (here e.g.: the queue has still space left or is not yet full).

Also the conditions we use for waiting are often only meant for rough, possible or necessary (but not sufficient) conditions and we still will have to check, if the state is indeed as expected or what we're looking for. Maybe another task got notified before us and already changed the state. That's also why "Condition.wait_for(predicate)" exists, to make that a combined and more compact affair without an explicit while-loop as in the Java-example. We might even get notified, even though the condition is actually NOT met!

The Java-documentation also states that conditions are used to group tasks/threads into sets, that should be awakened, when some common event occurs. So the Event-part is mainly concerned with collecting tasks, that are waiting on a same or similar thing and awakening/notifying them together as needed.