On Wed, Feb 6, 2019 at 8:52 PM Nils Bruin <nbr...@sfu.ca> wrote: > > On Wednesday, February 6, 2019 at 6:35:27 AM UTC-8, E. Madison Bray wrote: >> >> >> Which is being reached because AlarmInterrupt is a subclass of >> KeyboardInterrupt . I don't know why this doesn't happen then when, >> say, mashing Ctrl-C. I guess because IPython installs its own SIGINT >> handler or something. > > > In IPython proper the behaviour is different: > > > In [1]: import signal > > In [2]: signal.alarm(1) > Out[2]: 0 > > In [3]: Alarm clock > <exit> > > This is the same as in python: > > >>> import signal > >>> signal.alarm(1) > 0 > >>> Alarm clock > > It looks like this is just the default signal handler for python (the one > that just prints the signal name and exits) > > Note that cysignals.signals.AlarmInterrupt is our own invention, so if the > problem is inheriting from KeyboardInterrupt, we should probably not do that.
IIRC there is a good rationale for that, though I don't see it explicitly documented anywhere. I think it's simply that in most code where you would want to catch an AlarmInterrupt (i.e. you set an alarm on some code that should not be allowed to run for more than a certain amount of time), you would also likely want to break out of it manually with a Ctrl-C, and you would want those two cases handled the same. So you kill two birds with one stone this way, rather than having to write `except (AlarmInterrupt, KeyboardInterrupt)`. In other words, the AlarmInterrupt is treated sort of as an automatic KeyboardInterrupt on a timer. This can be avoided of course by explicitly writing `except (AlarmInterrupt, KeyboardInterrupt)`, but I do like the existing design on principle. I think in this case its better to address the specific problem. I find it odd that IPython would allow an interrupt arising from user code to break out of its event loop. It seems to happen in the case of code being run via signal handlers, because if I just enter `raise KeyboardInterrupt` at the prompt, this happens: sage: raise KeyboardInterrupt --------------------------------------------------------------------------- KeyboardInterrupt Traceback (most recent call last) <ipython-input-1-c761920b81b0> in <module>() ----> 1 raise KeyboardInterrupt KeyboardInterrupt: So, no problem. But I can reproduce the problem with Sage's alarm() using pure Python+stdlib like: sage: import signal sage: def raise_keyboard_interrupt(*args): ....: raise KeyboardInterrupt ....: sage: signal.signal(signal.SIGALRM, raise_keyboard_interrupt) 0 sage: signal.alarm(1) 0 I'm just not entirely user that the KeyboardInterrupt handling in IPython is entirely well considered here. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
