To put this another way: I see an uninterruptible infinite loop as a data loss bug on par with a segfault, since there's no graceful way to terminate the process and allow cleanup code to run.

For segfaults, we're willing to tolerate them, but we expect the reproducers to involve arcane coding contortions, not simple expressions like "sum(itertools.count())".

Now, the producer side check that Serhiy posted here only addresses part of the problem - there's also the question of making the consumption loops more robust by having them check for signals, and adding a ThreadExit equivalent to allow the interpreter to request shutdown of non-daemon threads other than the main thread.

But as long as we think it's a-OK for us to hang a user's session, causing them to lose all their unsaved/uncached data, then we're going to resist the extra code complexity required to account for these usability concerns. (And I realise they're not new concerns - they're just longstanding problems that folks have gotten used to tolerating and excusing)