On Mon, 14 Sep 2009 10:16:21 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
I think it's worth considering what the OP's real complaint is: namely, that (some? all?) C extensions can't be interrupted by ctrl-C as the user would expect. Is that a valid issue, or is it expected that Python has no control over what happens inside the C extension?
I think it's valid. It's expected that the USER will have some control over what's going on in a program - in particular, that they should be able to interrupt it pretty much any time barring a bug of some sort. The interaction between Python's default SIGINT handling and C extensions breaks that expectation. It's not clear what a good solution would be, though. This problem exists for pretty much all signal handlers - they don't get a chance to run if there's a misbehaving C extension executing. The simplest solution is to just not handle SIGINT by default, which raises the objection that try/finally doesn't "work". I don't think this will matter in most cases; the finally block is usually freeing up some resource that is going to be freed by the process exiting as part of default SIGINT behavior. We've certainly had similarly subtle changes that are much harder to deal with in the 2.X line. To me, the nasty part of such a change is the loss of traceback on SIGINT by default. During development, hitting C-C when the python code is in an infinite loop pretty reliably provides a traceback that nails down the problem. Yes, I could just boilerplate that into every program, but part of python's attraction is that such things are so seldom needed. I suspect this might be best dealt with by documenting how C extensions should behave with respect to signals - particularly SIGINT - and providing sample code for doing so. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org