[Idle-dev] Interruptable code?

Douglas S. Blank dblank at brynmawr.edu
Mon Dec 18 05:33:35 CET 2006

Just thought I'd post the details of what worked for me in interrupting a
loop in idle with no subprocesses and no print statements on WindowsXP.

Checking on PyShell.flist.pyshell.canceled did not work, because it
appears that "canceled" doesn't get set until "write()" is called.

But with that hint, I just add a bunch of write's in my code, like so:

def func():
    return None

Then I can control+c the following:

>>> while 1: func()

If you remove the write(), you won't be able to stop the program (short of
killing IDLE).

(I actually made it a bit smarter, so that it can run outside of IDLE, too.)

Thanks, again, for the hints.


On Sat, December 16, 2006 3:21 am, Kurt B. Kaiser said:
> "Douglas S. Blank" <dblank at brynmawr.edu> writes:
>> I notice that in IDLE when running with -n (no processes) that:
>>>>> while 1: 1
>> can be stopped with control+c, but:
>>>>> while 1: None
>> cannot. I realize that this is true because the second example doesn't
>> cause anything to be written in the IDLE window, and the first does.
> Yes. The cancel state is checked when PyShell.write() is called.
>> I see that running without the additional subprocess might make this a
>>hard bug to fix. But, is there something I can call like so:
>>>>> while 1: func()
>> where:
>> def func():
>>    # a call to check for control+c or update IDLE
>>    return None
> def func():
>     while True:
>           if flist.pyshell.canceled:
>                 break
> while True: func()
> (works w/o subprocess)
>> Some additional data:
>> - I can't use idle with sub processes (because I want to interact with
>> Tkinter in a single thread)
> If you run with the subprocess and construct Tkinter objects, they run in
> a process separate from the IDLE GUI.  This is an advantage in most cases!
> One of the objectives for implementing the subprocess was to separate
> the IDLE GUI from the user code.  The user code can be interrupted even
> in
> while True: pass
> (But IDLE Windows has problems with killing user code which is blocked.)
> --

Douglas S. Blank
Associate Professor, Bryn Mawr College
Office: 610 526 601

More information about the IDLE-dev mailing list