Logged In: YES 
user_id=31435

Sorry, I think this is a poor idea, and mdehoon's suggestion 
for turning a correct use of .wait() into a doubly buggy one 
illustrates why:  there's no guarantee that self._empty() will 
return false just because .wait() returns without timing out --
 .wait() returning just means that it may not be a waste of 
time to check for the desired condition.  "notifying" a condvar 
emphatically does not mean that the desired condition holds, 
and any number of other threads can run for any amount of 
time between the times a condvar is notified and some wait()
er wakes up (so even if the desired condition does hold at the 
time notify() is called, it may not anymore by the time a wait()
er wakes).

The check should always be done when .wait() doesn't time 
out, and even if .wait() does time out, self._empty() may 
return false anyway.

Note too that .wait()'s caller holds the associated mutex 
regardless of whether return is due to timeout or notify, and 
the caller needs to release it again in either case.  Creating a 
distinction based on return value creates a new opportunity to 
screw up that part too.

I don't understand this:

> An example is using a condition variable as a sentinel
> for exiting a loop or a polling thread. Using the
> return value one can decide whether to exit the loop or
> not.)

To the extent that I might understand it, it sounds like a 
condvar is gross overkill, and that you'd want something 
simpler (perhaps an Event) in those cases.  But I can't flesh 
out the code you have in mind there.