> 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.