On Thu, 12 Jun 2003, Guido van Rossum wrote: > The interrupt module currently uses PyErr_SetInterrupt(), which can > only raise KeyboardInterrupt. > > Let's not generalize this until there's a need. Then, let whoever has > the need add the generalization. In that past, there have been a few times where it would have been very convenient to terminate/signal another thread by posting an exception to it. Using KeyboardInterrupt to do so is okay, although it seems like something of a kludge. > I'm actually a bit wary of such a generalization, because > KeyboardInterrupt is currently the only *asynchronous* exception that > code needs to worry about. There is plenty of code that gives > KeyboardInterrupt special treatment, [..] Code that gives special status to KeyboardInterrupt doesn't worry me at all. What I am wary of is code that is not written to be exception safe in the presence of unexpected exceptions (not just asynchronous ones). The example I was working on yesterday involved KeyboardInterrupts generated from an SSL socket in httplib's SSL readline method. A keyboard interrupt will result in data read from the socket and then stored in a local variable to be lost. Of course, this error wasn't very likely before I patched the SSL module to check for interrupts, but that is beside the point. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4