[Idle-dev] Fix for long delays

[Tal Einat]

Bruce Sherwood wrote:
> Dave Scherer suggested that I join this discussion, as I represent a
> constituency of literally thousands of college students who use IDLE
> in intro physics classes at a number of major universities (I'm also a
> developer of VPython). Let me offer an explanation of goals,
> somewhat independent of implementation issues.
[snip]

Hi Bruce, thanks for joining us.

I have to say I had no idea you had so many students using your
system, of which IDLE is a part. It's good to know, and great to hear
your experiences and ideas!

> Some time ago, there was some change to IDLE that had the very
> unfortunate effect of leaving an old graphics window on the screen
> when you pressed F5 to run again, with the result that the more
> times you ran, the more old graphics windows cluttered up the
> screen. When Dave became active again in VPython development,
> he realized what the problem was, and that was his original
> motivation for patching IDLE. In the process he also identified
> some related problems, which his patch addresses.

I would be interested to hear which change caused this and what the
problem was. There should be way to patch mainstream IDLE so that it
plays well with VPython, and I'd be glad to help work it out.

David Scherer wrote:
> The problem with loading IDLE from the shell context menu is
> that the default binding runs IDLE with the "no subprocess"
> command line option (you can see this in the output window if
> you look, and you can correct it by changing the command
> line for the "Edit" action in explorer by hand).  My guess is
> that this is because of some real or perceived problem with
> running multiple instances of IDLE in the usual subprocess
> mode.  I think it would be a good idea to remove the "no
> subprocess" option from the shell binding, and fix any problem
> with the coexistence of multiple subprocess-based IDLE
> instances.

Douglas S. Blank wrote:
> I agree that for the us the "no subprocess mode" causes confusion. I'd
> vote to make get rid of it, or at least to not make it the default.

I certainly agree that using a subprocess should always be the
default. However, no-subprocess mode is very useful in certain cases,
such as debugging IDLE itself, so we'd need a good reason to get rid
of it.

The reason no-subprocess mode is the default on Windows is to avoid
trying to open more than subprocess, since opening a second one
usually fails because of port clashes. About a year ago I worked up a
patch: http://bugs.python.org/issue1529142, "Allowing multiple
instances of IDLE with sub-processes". The problem with it is that I
haven't been able to get it accepted, because of lack of interest and
its relative complexity.

If like me you wish mainstream IDLE to always open without a
subprocess by default, including from Windows Explorer's context menu,
please help me to get this patch accepted! More reviews posted on the
afore-mentioned URL can help, as well as showing support here on
idle-dev.

Douglas S. Blank wrote:
> I'd also get rid of that scary message:
>
>    ****************************************************************
>    Personal firewall software may warn about the connection IDLE
>    makes to its subprocess using this computer's internal loopback
>    interface.  This connection is not visible on any external
>    interface and no data is sent to or received from the Internet.
>    ****************************************************************
>
> Surely we don't need that, or could test to see if everything started ok
> and only display it then?

Gregor Lingl suggested removing the firewall warning back in July
2006: http://mail.python.org/pipermail/idle-dev/2006-July/002480.html
This resulted in a patch I wrote which moves the message to the Help
menu: http://bugs.python.org/issue1529018
(notice Kurt's comment to my patch)

I like your idea of displaying the firewall message only if there is
some kind of problem. Perhaps the firewall message should be made part
of the "failed to connect to subprocess" error message? Especially if
the multiple-subprocesses issue is resolved, connection failures
should become very rare, and mostly due to firewall software and such.

Douglas S. Blank wrote:
> Finally, having f5 restart the shell was absolutely the wrong thing for
> us. We usually have an open connection to a robot, and we're writing code
> to control it. I submitted a patch to allow an alternate control+f5 to run
> the module without restarting the shell.

I posted this patch a few months ago: http://bugs.python.org/issue2049
Kurt and I discussed it for a while, but in the end the discussion
died out before either of us was convinced. Kurt didn't like the patch
because it added another option to the menu -- with it, the Run menu
has both a "Run Module" entry as well as "Run Module & Restart Shell",
with the keyboard bindings F5 and Ctrl+F5 respectively. Maybe we
should find a better way; this was the best that I had come up with at
the time.

As with the other patches, support of this patch will really help move
things along. Ideas on how to simplify the interface could also help.



Thank you for explaining your reasons for wanting immediate
sub-process termination. Reading these has me mostly convinced that
immediate termination is a good idea. I would still like to hear
opinions from people using IDLE in other environments, and what Kurt
has to say, to make sure we're not ignoring any good reasons not to do
this.

- Tal