> ThreadPoolExecutor introduces additional waiting of its own, and it is this wait the PR adds an option to disable.

[next post]

> Thanks for the clarification, I didn't know about the change to non-daemon threads.

> I still think this patch is useful, and won't harm general use because it is opt-in, just like daemon threads themselves. I suggest to update the PR to specify non-waiting pool at the point of creation rather than in shutdown(). (That will also make it more acceptable for the same option not being supported for process pools - it is ok for constructor signatures to differ.)

Yes, but if you simply make the ThreadPoolExecutor forget about the thread, then all that it does is divert the wait to occur at a later time. In this case, it would get stuck at `threading._shutdown()` (where all non-daemon threads are joined) instead of `executor.shutdown()` since they no longer use daemon threads.

The only way I could see this to work as intended without making any changes to threading would be to optionally use daemon threads and avoid joining the threads in `executor.shutdown()` if `wait_at_exit` is set to False in the constructor for the executor. But at the least, users would have to be made aware in the documentation that this could lead to significant resource finalization issues, and potential incompatibility with subinterpreters. 

Otherwise, they may end up accidentally shooting themselves in the foot (which we certainly want to avoid). I'm also somewhat concerned that it may end up getting used to cover up actual bugs. 

IMO, it also would require some fairly extensive testing to make sure it works as intended, which the patch currently lacks. So in order to implement this properly, it would require a significant amount of additional time investment beyond what has been put into the existing patch.