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 _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
