Sworddragon added the comment: > but what if there is a bug in your code?
Bugs in a python application can be fixed by the user while a specific behavior of the interpreter can't. Maybe you are also thinking in the wrong direction. Nobody wants a solution that traps the user forever. Also KeyboardInterrupt is not the only problem that is affected by this race condition (but it is the best example to demonstrate it). But I have made some thoughts about a potential solution (maybe it needs fine-tuning, depending on the python developing-policies or if I have overlooked something): The idea contains overloading on a try/except-block. We will have the old (current) except block that acts as we know it and we will have a function-like except block "except(string_message, int_exitcode):". The function-like except block is a policy for any nested exception. Instead of triggering the nested exception it will print the first argument to stderr and exit with the second argument. While the interpreter is doing this as a built-in call it disables any potential exception-triggering in this time. This solution will eliminate the race condition without catching the user in an infinite recursion. What do you think of this idea? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18836> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
