Currently the wait method on threading.Event always returns None, even if a timeout is given and the event is not set.
This means that there is no way to determine whether the wait method returned because the event was set, or because the timeout period expired, without querying the event status again:

x.wait(3)
if x.isSet():
  # do stuff

Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out

It would be great to be able to do:

if x.wait(3):
  # do stuff

This should also not affect any existing code as it shouldn't be relying on the return value from x.wait anyway

This one-line change to threading.py makes Event.wait() return isSet().
 Also includes the corresponding update to documentation in threading.rst.

Tim, you said this was a bad idea for conditions in #1175933 - is the
same true for Events?

I would like to add my support for this change.  As David described, it
is often useful to know why the x.wait() has returned, not just that it has.

I agree this would be a worthwhile addition too. Unfortunately given the
current schedule this will probably have to wait for 2.7/3.1.

A test should be added to the patch, and then I think it could go in.

Thanks, Antoine. I will re-check the patch against trunk and add tests 
this week.

Looking at this, I think this change is fine.  The _Event class itself
holds the condition that it's checking for, and the is_set() method
doesn't acquire the lock, so there's no reason to prefer

e.wait()
if e.is_set():
    GOT_IT()

over

if e.wait():
    GOT_IT()

IOW Tim's reasoning in #1175933 for rejecting a similar change to
_Condition.wait() doesn't apply here.  I think we can go ahead without
waiting for Tim to confirm this.

Added a pony test and committed in r70883.