Hi Steve, a couple things to preface my following comment. (1) Didn't mean to suggest that the current behavior is a bug. I don't think it is a bug, rather that it can easily lead to bugs. (2) Sorry for tagging the previous versions, I'm not familiar with the ticket system and didn't realize I was asking for (nor do I want) this to be changed in previous versions as well. I thought it just means what versions was this ticket relevant to.

I do realize and appreciate the basic object model regarding `bool(obj)`, and there is nothing in the threading documentation or the language as a whole that would lead me to believe that Events should be evaluated for their truthiness directly. However, I would like to expand on my case further before closing the ticket.

I believe there is a fundamental difference in the "perception" of what an Event object represents vs most other objects, *with respect to how bool should be evaluated on it*. It undeniably draws very clear parallels to a true boolean flag, and is often used as a surrogate for such. I realize it is more than that, that it's used for synchronization as well as other things, but the fact that Event is so often assigned to a variable called "flag" or a variable that implies a discrete boolean state (like my original stop_thread example), rather than a variable name that encompasses the full concept of an event, is a good indication that this is how people view/use the object. 

Given that the concept of Event and a boolean flag are so closely intertwined, I think that (but am *not* suggesting the following) it could even be considered appropriate for `bool(not_set_event)` to evaluate to False.  Again, I am not suggesting this, as I realize that an Event is more than just it's underlying "set" state. But, this is why I think that more often than not it is Ambiguous what a developer actually intended by directly evaluating such.

Now, in terms of what the current behavior enables us to do, in other words, by adopting this change, what abilities in the language/threading framework are we losing. The only thing I can think of is the ability to do this: `event = event or Event()`. I don't have statistics on this but I would make the assumption, and I believe it's a safe one, that the vast majority of situations where Event shows up in a boolean evaluated statement (e.g. if, while, not, and/or) is as `event.is_set()`. So much so, that I would even go so far as to make the assumption that there is a decently high probability that if someone does write `event or/and other_variable` it was done so in error. However, this is nothing but an assumption, with no evidence to back it up, so really the point I want to get across here is that there is not much utility in `bool(event)` and I don't think we're hindering the language in any way by forbidding it.

With respect to backwards compatibility, while it is not backwards compatible, it is very refactor friendly. First of all, there will not be many properly used cases (e.g. `event = event or Event()`) where this would show up in the first place. And second, since we're raising an exception rather than returning a different value, we won't introduce unexpected behavior to any existing use cases.

All this said, any bugs that this behavior can lead to, are most likely easily caught and resolved. But, I think that this change would be, and only be, a benefit to developing threaded applications in Python.