> Stolen wakeups are a fact of life though, even in cpython's
> implementation of condition variables.  And for the user of a
> condition variable the difference is so subtle as to not warrant
> special mention.

I don't think it's a subtle difference. Being woken up too late is not
the same as being woken up spuriously.
Also, the term "stolen wakeup" makes it unnecessarily dramatic. There is
no "stealing" involved here.

> Look anywhere in the internets and you will find this, including here:
> http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html

Thanks, will take a look.

> Quite the contrary, we should be careful to never overspecify our
> interfaces so that we may not change their ipmlementation details
> later.

The interface is already, de facto, specified by its one and only
implementation, which has been in use for a long time. It's also
specified by its documentation, before it was silently modified by you.

There's probably code out there that relies on wait() not returning
prematurately.

> A good summary of the situation and the reason for the specification
> can be found here:
> http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups

So the reason appears to be:

        “Spurious wakeups may sound strange, but on some multiprocessor
        systems, making condition wakeup completely predictable might
        substantially slow all condition variable operations.”

Python is a high-level language, so making condition variable ops
"substantially" slower is not a blocking issue for us.

What follows is even less enlightening:

        “The intent was to force correct/robust code by requiring
        predicate loops. This was  driven by the provably correct
        academic contingent among the "core threadies" in the working
        group, though I don't think anyone really disagreed with the
        intent once they understood what it meant.”

> The comment I added to the documentation clarifies the reason why
> other examples in the docs were using while loops and teaches shows
> people how to use these constructs in a robust manner.

Teaching people to use loops is fine. But there's no need to mislead
them with inaccurate descriptions of the implementation's behaviour.

> Unless you disagree, I'll add these test cases in addition to the
> broken one, which can then be fixed or removed later if it turns out
> to be problematic to other people.

Really, can you stop being aggressive? You haven't proved that test is
wrong, and it passes consistently fine on all buildbots.

If you don't agree with what is being tested, that's another matter. But
please accept that the test is ok w.r.t. Condition's specified
behaviour.