We shouldn't be testing implementation details.  The Condition variables are canonically prone to "spurious wakeups" and "stolen wakeups".  The fact that the current implementation doesn't have them shouldn't place that burden on future implementations of threading.Condition on this platform.
From the docs: "Note: Condition variables can be, depending on the implementation, subject to both spurious wakeups (when wait() returns without a notify() call) and stolen wakeups (when another thread acquires the lock before the awoken thread.) For this reason, it is always necessary to verify the state the thread is waiting for when wait() returns and optionally repeat the call as often as necessary."

2) You would build a lock yourself if you wanted exact control over its behaviour.  In this case, we are just doing what threading.Lock() does, but it could be more complicated.  At any rate, it proves a useful toy usage of a condition variable in the context of making sure that it works properly as part of the unit tests.

I could leave the original test in place and just add the new ones, but the old test is at least provably a subject to a race condition as per the original issue.