[Python-Dev] Catch SIGINT at Python startup

Guido van Rossum guido at python.org
Mon Mar 8 22:06:36 CET 2010

On Mon, Mar 8, 2010 at 12:50 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Le lundi 08 mars 2010 18:47:18, Guido van Rossum a écrit :
>> Actually it sounds like there's some overly general except clause
>> somewhere that should be adjusted to catch just "Exception" instead of
>> "*".
> Most of my patches (for SIGINT) are exactly doing that: check the exception
> type instead of "if (result == NULL) PyErr_Clear();" (try/except: pass). About
> initsite(): I consider any error as fatal. If initsite() failed, something
> goes wrong.
> I think that my patches are enough to catch SIGINT during the Python
> initialization. I used different tricks to test Python: add kill(getpid(),
> SIGINT), use "signal SIGINT" in gdb, add
> PyErr_SetNone(PyExc_KeyboardInterrupt), ... valgrind is a very good tool to
> slow down any process :-D

I see. I thought for a moment that by "fatal" you meant something like
calling Py_FatalError().

I am trying to remember why I made site.py failures non-fatal in the
first place. I don't have any specific recollection but it must've
been either from before the separation between site.py (part of the
stdlib) and sitecustomize.py (site-specific) or out of a worry that if
some external cause broke site.py (which does a lot of I/O) it would
be a fatal breakdown of all Python execution.

I am fine with making an exception for KeyboardInterrupt (and other
exceptions not deriving from Exception but only from BaseException)
but I don't think I want to go as far as making all errors coming out
of site.py fatal. (At least not without more understanding of the use
case for making these non-fatal in the first place.)

OTOH I think the try/except in site.py around the execution of
sitecustomize.py might be changed so that it prints a full traceback
whenever it raises an exception other than ImportError or, again,
exceptions inheriting from BaseException but not from Exception. IOW I
think that exceptions coming out of sitecustomize.py should continued
to be treated non-fatally, apart from ^C and friends, but I think that
exceptions coming out of site.py *might* be considered more fatally
once the change to exceptions coming out of sitecustomize.py is made.

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list