Marius Gedminas added the comment: Somewhat unrelated nitpick: I'm not very happy that _InterruptHandler doesn't return early after calling the original handler.
It's all very well, if the original handler raises or does nothing at all, but if it's a user-installed handler that does something (e.g. print a stack trace to sys.stderr), then it might get called twice (or three times, after my patch). AFAIU the situation would have to be pretty contrived: - there's a user-provided SIGINT handler - unittest installs its own on top - one of the tests (or some test runner plugin) overrides the SIGINT handler again - user presses Ctrl-C - the current SIGINT handler delegates to the unittest _InterruptHandler - _InterruptHandler notices it's not the current handler and delegates to the original one - the original handler doesn't raise - _InterruptHandler.__call__ doesn't return early and goes on to perform the "if called check" - if this is a second Ctrl-C, the original handler will get called a second time for the same Ctrl-C event - if there are no registered results, my new code will cause the original handler to get called again (a third, or a 2nd time for the same Ctrl-C event) Is there a good reason not to add early returns after defering to the original handler? Maybe it's desired that ^C should stop the test suite even if a test overrides the SIGINT handler but delegates back to the unittest one? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25900> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
