This seems like a good idea to me.

• What does thread.is_alive() return?
• I think the exception should not be conditional on not having a timeout specified. There's no way it can succeed, so we should just raise the exception immediately like we do when trying to join your own thread. You can also end up with threading.join(timeout=...) calls in an infinite loop.

I think the exception should not be conditional on not having a timeout specified

I agree with Sam.

What does thread.is_alive() return?

True. Threads that are already done can be joined normally.

I think the exception should not be conditional on not having a timeout specified.

In a finalizer, wouldn't it be OK to wait a bit for graceful termination (using join with a timeout), and then do some teardown regardless of whether the thread survived?
(If Python is being finalized, the thread would of course always survive -- but you might not be writing the code only for that case.)

Raising an exception would mean you skip that teardown, unless you have a try/except around join.

IOW, to me, the reasoning is not as clear-cut here as in the “hang the only Python thread that can run” case.

You can also end up with threading.join(timeout=...) calls in an infinite loop.

Well... You can even write an infinite loop without any join at all! :)
I guess I'm not trying to prevent hangs entirely, just make them easier to diagnose. IMO, a while thread.is_alive() loop is much easier to grok than an internal lock becoming un-acquirable.

I wrote the code to hang even with timeout; I'll update the PR if you still think that's the way to go.

Updated to raise even with timeout.

I'll merge on ~Friday if there are no objections.

... And I went offline for a month after writing that.

I'm back now; merging.