> A Thread.excepthook() method does not allow to notify exceptions raised in C-created threads ("dummy threads").

The main difference between sys.excepthook and threading.excepthook is that the threading hook displays the thread name. Which output do you expect if you don't pass a threading.Thread object (which has a 'name' attribute)? The thread identifier from _thread.get_ident()?

I can easily modify the default hook implementation to support args.thread=None and displays _thread.get_ident() as the name instead.


> Also, as I said already, you can get the current thread by calling threading.current_thread() in the except hook. There is no need to pass it explicitly to the except hook.

I understand that your plan is to use sys.excepthook to handle threading.Thread uncaught exception.

My main concern is that sys.excepthook can fail on importing the threading module. One solution would be to import threading when the sys module is created and keep a strong reference to threading.current_thread(). But I dislike this idea.

I already raised my concern, but so far, you didn't explain how you plan to fix this practical issue.

Moreover, the current threading code is quite complex. My guess is that this complexity is needed to display exception very late during Python shutdown, when module attributes are set to None and import no longer works.

I would prefer to not move this complexity into sys.excepthook which has currently a simple implementation.

--

Daemon threads are evil. We should drop this nasty feature... but I would prefer to not block this issue by the removal of daemon threads, since I'm sure that a lot of code rely on them and so it will be really hard to really remove them.