[Idle-dev] Fix for long delays

Douglas S. Blank dblank at brynmawr.edu
Mon May 26 15:30:29 CEST 2008

On Mon, May 26, 2008 8:51 am, Tal Einat said:
> Douglas S. Blank wrote:
>> On Mon, May 26, 2008 5:42 am, Tal Einat said:
>>> David Scherer wrote:
>>>> Here is a patch to the IDLE shipped with Python 2.5.2 that I regard as
>>>> a
>>>> bug
>>>> fix.  Specifically, it makes IDLE terminate its subprocess on Windows
>>>> with
>>>> TerminateProcess (instead of just by closing a socket), and on UNIX
>>>> with
>>>> SIGKILL instead of SIGTERM.
>>> Is this really wanted behavior?
>> We have added very similar code to a startup wrapper around IDLE that
>> does
>> the same thing. We have the same situation where the serial port code
>> talking to a robot in the background thread won't let go, and we have to
>> kill it.
>> However, this fix doesn't allow you to have two IDLE's running. The
>> second
>> one started will kill the first. In fact, ours kills all running Python
>> processes---not generally a good idea.
> In your case I understand the need, but this could be considered a
> special use case - to add such a feature to IDLE we would need to show
> that it would be generally useful.
>> Having the background stop quickly would be useful.
> Can you expand on this? In which cases would it be useful?
>> I don't think I would add this patch to IDLE... too many side effects. I
>> think I would fix it in other ways:
>> 1) when closing idle, have it kill the one background process
>> immediately.
> Again - why immediately? Why not allow a certain delay, monitor the
> sub-process, and only kill it if it is still running after the delay?
> The duration of the delay could be configurable, and setting it to
> zero would kill the sub-process immediately.

I would think that having it run in the background for greater than 0
seconds would be a special use-case; zero should be the default. If you
close IDLE all should stop, right?

>> 2) when starting IDLE, check for a running version, and have it open the
>> file/use the current Python Shell. That would prevent starting multiple
>> shells which are trying to do the same thing (ie, connect on to serial
>> ports, etc).
>> 3) allow idle to have multiple shells (in case you really do want to do
>> that)
> Hmm. I must say I don't really see the benefit here if you allow
> multiple shells - you'd still have the same problems that you have
> now. And if you only allow one shell, that's very restrictive - I'm
> pretty sure we don't want to do that.

There are two issues here: whether you want two shells, and how you start
IDLE. Currently, starting IDLE with a right-click and selecting "Edit with
IDLE" automatically gives you a new process that can't use the previous
shell. I'd suggest separating these two issues by having #2 and #3.

> I can understand why in your specific case you would want #2 - you
> want to ensure that there is only one IDLE shell. However, you're the
> first I've ever heard wanting this from IDLE, whereas I know plenty of
> users who often run multiple IDLE shells in parallel.

I'm not arguing against running multiple IDLE shells in parallel... I'm
suggesting that that is not always want the student wants, but that is the
default behavior (from the OS window---of course you can get around this
by opening the programs from inside IDLE. But new users don't understand
this distinction). I'd like to make the default be the same IDLE running,
and then one can control the multiple shells from there.


> - Tal

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

More information about the IDLE-dev mailing list