homepage

> for everybody who is not *programming* python (imagine there is a *real* user) the tracebacks are useless. Even worse, because the error messages are *changing*, because of different library parts not catching the exception.
Well, I also use it sometimes ;-)
> The problem here is that the user is confronted with unwanted output, produced by the interpreter, which is not possible to be caught by a programmer to prevent this situation happening.
You can start the interpreter with '-S' to avoid importing the site
module, then:
"""
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
import site
site.main()
[...]
"""
or
"""
try:
 import site
 site.main()
 import signal
 signal.signal(signal.SIGINT, signal.SIG_DFL)
except KeyboardInterrupt:
 whatever
[...]
"""
Or we could change Py_InitializeEx() to setup the signal handlers
after having imported the site module:
"""
--- cpython-93769b8ff40b/Python/pythonrun.c 2012年01月19日
10:29:48.000000000 +0000
+++ cpython/Python/pythonrun.c 2012年03月20日 11:27:37.000000000 +0000
@@ -313,9 +313,6 @@
 if (initfsencoding(interp) < 0)
 Py_FatalError("Py_Initialize: unable to load the file system codec");
- if (install_sigs)
- initsigs(); /* Signal handling stuff, including initintr() */
-
 initmain(); /* Module __main__ */
 if (initstdio() < 0)
 Py_FatalError(
@@ -333,6 +330,9 @@
 if (!Py_NoSiteFlag)
 initsite(); /* Module site */
+
+ if (install_sigs)
+ initsigs(); /* Signal handling stuff, including initintr() */
"""
Note, however, that there will always be a race window, if the signal
is delivered after the signal handlers have been setup and the first
line of the user code is executed.