From dscherertemp at gmail.com Thu May 15 00:15:10 2008 From: dscherertemp at gmail.com (David Scherer) Date: Wed, 14 May 2008 18:15:10 -0400 Subject: [Idle-dev] Fix for long delays In-Reply-To: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> Message-ID: <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> Hi all, 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. The Windows change is especially important, because without it IDLE rather often fails to end my programs in a timely fashion when I close the output window, restart the shell, or just press F5 to run the program again. I think, however, that the behavior on all platforms should be to terminate the user program immediately whether or not it cooperates; that's what I expect when I give such a command to an IDE, and a user program running disconnected from its output terminal is not a good thing. I'm working on Windows at the moment, so I'd greatly appreciate it if someone on the list can test my changes on a platform that has os.kill. I suspect that the code in run.py has some quirks that exacerbate the bad behavior without the patch (for example, why the 10 second timeout in MyHandler.exithook?), but my patch appears to make them irrelevant, as well as deal with really nasty ways that the running program could freeze itself up (e.g. a C extension that blocks without releasing the interpreter lock). If there are any platforms other than Windows without os.kill, it might be worth at least getting rid of the timeout. Comments or questions? Dave --- c:\temp\Python-2.5.2\lib\idlelib\PyShell.py 2006-10-12 > 03:57:24.000000000 -0400 > +++ c:\python25\lib\idlelib\PyShell.py 2008-05-14 17:09:29.958875000 > -0400 > @@ -12,6 +12,7 @@ > import traceback > import types > import macosxSupport > +import subprocess > > import linecache > from code import InteractiveInterpreter > @@ -39,10 +40,31 @@ > IDENTCHARS = string.ascii_letters + string.digits + "_" > LOCALHOST = '127.0.0.1' > > -try: > - from signal import SIGTERM > -except ImportError: > - SIGTERM = 15 > +if hasattr(os, 'kill'): > + try: > + from signal import SIGKILL > + except ImportError: > + SIGTERM = 9 > + > + def kill( proc ): > + try: > + os.kill( proc.pid, SIGKILL ) > + except OSError: > + # process already terminated: > + return > + else: > + try: > + proc.wait() > + except OSError: > + return > +elif sys.platform[:3] == 'win': > + import ctypes > + def kill( proc ): > + ctypes.windll.kernel32.TerminateProcess( int(proc._handle), -1 ) > + proc.wait() > +else: > + def kill( proc ): > + pass # Hope the RPC mechanism will do the job > > # Override warnings module to write to warning_stream. Initialize to send > IDLE > # internal warnings to the console. ScriptBinding.check_syntax() will > @@ -343,11 +365,11 @@ > > port = 8833 > rpcclt = None > - rpcpid = None > + rpcproc = None > > def spawn_subprocess(self): > args = self.subprocess_arglist > - self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args) > + self.rpcproc = subprocess.Popen( [sys.executable] + args[1:] ) > > def build_subprocess_arglist(self): > w = ['-W' + s for s in sys.warnoptions] > @@ -463,17 +485,7 @@ > > def unix_terminate(self): > "UNIX: make sure subprocess is terminated and collect status" > - if hasattr(os, 'kill'): > - try: > - os.kill(self.rpcpid, SIGTERM) > - except OSError: > - # process already terminated: > - return > - else: > - try: > - os.waitpid(self.rpcpid, 0) > - except OSError: > - return > + kill( self.rpcproc ) > > def transfer_path(self): > self.runcommand("""if 1: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyeko_ogiramoi at yahoo.co.uk Tue May 20 18:51:59 2008 From: nyeko_ogiramoi at yahoo.co.uk (Ogiramoi Nyeko Paul) Date: Tue, 20 May 2008 16:51:59 +0000 (GMT) Subject: [Idle-dev] posting Message-ID: <126032.43988.qm@web26701.mail.ukl.yahoo.com> __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahmood.saghaei at gmail.com Fri May 23 08:28:32 2008 From: mahmood.saghaei at gmail.com (Mahmood saghaei) Date: Fri, 23 May 2008 10:58:32 +0430 Subject: [Idle-dev] invisible underscores Message-ID: <903704440805222328g2939e419oef97d40a197a8719@mail.gmail.com> Hi all I am a beginner both to python and IDLE. I am not sure this is the right listing for asking questions and reporting problems. Anyhow I appreciate any solution to the following problem in my IDLE 2.5.2 installation on a Linux/Ubuntu platform: underscores (underlines) are not visible in the editor and in the shell. for example raw_input looks like raw input. Though there is no functional problem in the environment, I am not happy with it. I tried the options, but there was nothing there for underscores. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcronin at egh.com Fri May 23 16:38:47 2008 From: jcronin at egh.com (Jonathan Cronin) Date: Fri, 23 May 2008 10:38:47 -0400 Subject: [Idle-dev] invisible underscores In-Reply-To: <903704440805222328g2939e419oef97d40a197a8719@mail.gmail.com> References: <903704440805222328g2939e419oef97d40a197a8719@mail.gmail.com> Message-ID: <763AFE33-D475-48E8-BDFF-48B4A7997A3F@egh.com> On May 23, 2008, at 2:28 AM, Mahmood saghaei wrote: > underscores (underlines) are not visible in the editor and in the > shell. for example raw_input looks like raw input. Though there is > no functional problem in the environment, I am not happy with it. I > tried the options, but there was nothing there for underscores. Try setting a different font in the editor. I haven't had this problem in IDLE, but I have had it in other softwar,e which seems to clip the bottom row of pixelds in characters. If the underscore is thin, it disappears. Jonathan From mahmood.saghaei at gmail.com Fri May 23 17:23:08 2008 From: mahmood.saghaei at gmail.com (Mahmoud Saghaei) Date: Fri, 23 May 2008 19:53:08 +0430 Subject: [Idle-dev] invisible underscores [solved] Message-ID: <4836E15C.1040007@med.mui.ac.ir> Thank you for replies. Setting the font to Bitstream vera sans mono at size 8 worked Mahmoud From taleinat at gmail.com Mon May 26 11:42:25 2008 From: taleinat at gmail.com (Tal Einat) Date: Mon, 26 May 2008 12:42:25 +0300 Subject: [Idle-dev] Fix for long delays In-Reply-To: <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> Message-ID: <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> 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? Isn't killing processes with SIGKILL considered bad practice, to be used only when you *really* *must* have the process terminate *now*? (I honestly don't know this, if someone knows - please answer.) Similarly, are we sure that TerminateProcess on Windows doesn't have any side-effects? > The Windows change is especially important, > because without it IDLE rather often fails to end my programs in a timely > fashion when I close the output window, restart the shell, or just press F5 > to run the program again. I think, however, that the behavior on all > platforms should be to terminate the user program immediately whether or not > it cooperates; that's what I expect when I give such a command to an IDE, > and a user program running disconnected from its output terminal is not a > good thing. > I'm not sure I understand what you mean - do you mean that you expect IDLE to shut down its sub-process immediately when you close it? Why does having the sub-process around for a few more seconds bother you? One could argue that it should be killed harshly if it does shut down cleanly in a minute or so, but that's not what you're proposing - if I understand correctly, you want it killed immediately no matter what. > I'm working on Windows at the moment, so I'd greatly appreciate it if > someone on the list can test my changes on a platform that has os.kill. > I'd be glad to test this on an OSX 10.5 box, once we agree on the conceptual issues... > I suspect that the code in run.py has some quirks that exacerbate the bad > behavior without the patch (for example, why the 10 second timeout in > MyHandler.exithook?), but my patch appears to make them irrelevant, as well > as deal with really nasty ways that the running program could freeze itself > up (e.g. a C extension that blocks without releasing the interpreter lock). > If there are any platforms other than Windows without os.kill, it might be > worth at least getting rid of the timeout. > IIRC the timeout is there for a reason, although it doesn't come to mind ATM. Perhaps Kurt or one of the other more senior IDLE developers > Comments or questions? > You also have a bug - the second place where you check for an ImportError you're not setting the correct variable (SIGTERM instead of SIGKILL). - Tal From dblank at brynmawr.edu Mon May 26 14:01:58 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon, 26 May 2008 08:01:58 -0400 (EDT) Subject: [Idle-dev] Fix for long delays In-Reply-To: <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> Message-ID: <54362.71.59.123.159.1211803318.squirrel@webmail.brynmawr.edu> 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. > Isn't killing processes with SIGKILL > considered bad practice, to be used only when you *really* *must* have > the process terminate *now*? (I honestly don't know this, if someone > knows - please answer.) Similarly, are we sure that TerminateProcess > on Windows doesn't have any side-effects? This is especially useful on Windows, and has no other side effects (other than killing all running Pythons). >> The Windows change is especially important, >> because without it IDLE rather often fails to end my programs in a >> timely >> fashion when I close the output window, restart the shell, or just press >> F5 >> to run the program again. I think, however, that the behavior on all >> platforms should be to terminate the user program immediately whether or >> not >> it cooperates; that's what I expect when I give such a command to an >> IDE, >> and a user program running disconnected from its output terminal is not >> a >> good thing. >> > I'm not sure I understand what you mean - do you mean that you expect > IDLE to shut down its sub-process immediately when you close it? Why > does having the sub-process around for a few more seconds bother you? > One could argue that it should be killed harshly if it does shut down > cleanly in a minute or so, but that's not what you're proposing - if I > understand correctly, you want it killed immediately no matter what. Having the background stop quickly would be useful. >> I'm working on Windows at the moment, so I'd greatly appreciate it if >> someone on the list can test my changes on a platform that has os.kill. >> > I'd be glad to test this on an OSX 10.5 box, once we agree on the > conceptual issues... > >> I suspect that the code in run.py has some quirks that exacerbate the >> bad >> behavior without the patch (for example, why the 10 second timeout in >> MyHandler.exithook?), but my patch appears to make them irrelevant, as >> well >> as deal with really nasty ways that the running program could freeze >> itself >> up (e.g. a C extension that blocks without releasing the interpreter >> lock). >> If there are any platforms other than Windows without os.kill, it might >> be >> worth at least getting rid of the timeout. >> > IIRC the timeout is there for a reason, although it doesn't come to > mind ATM. Perhaps Kurt or one of the other more senior IDLE developers > >> Comments or questions? 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. 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) My $.02 -Doug > > You also have a bug - the second place where you check for an > ImportError you're not setting the correct variable (SIGTERM instead > of SIGKILL). > > - Tal > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From taleinat at gmail.com Mon May 26 14:51:15 2008 From: taleinat at gmail.com (Tal Einat) Date: Mon, 26 May 2008 15:51:15 +0300 Subject: [Idle-dev] Fix for long delays In-Reply-To: <54362.71.59.123.159.1211803318.squirrel@webmail.brynmawr.edu> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> <54362.71.59.123.159.1211803318.squirrel@webmail.brynmawr.edu> Message-ID: <7afdee2f0805260551l294a99bci5e5eea9d26ce7af9@mail.gmail.com> 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. > 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. 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. - Tal From dblank at brynmawr.edu Mon May 26 15:30:29 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon, 26 May 2008 09:30:29 -0400 (EDT) Subject: [Idle-dev] Fix for long delays In-Reply-To: <7afdee2f0805260551l294a99bci5e5eea9d26ce7af9@mail.gmail.com> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> <54362.71.59.123.159.1211803318.squirrel@webmail.brynmawr.edu> <7afdee2f0805260551l294a99bci5e5eea9d26ce7af9@mail.gmail.com> Message-ID: <40811.71.59.123.159.1211808629.squirrel@webmail.brynmawr.edu> 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. -Doug > - Tal > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From Bruce_Sherwood at ncsu.edu Mon May 26 18:07:01 2008 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Mon, 26 May 2008 10:07:01 -0600 Subject: [Idle-dev] Fix for long delays Message-ID: <483AE025.9070004@ncsu.edu> 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. When Dave created VPython (vpython.org) in 2000, he also created a new version of IDLE which with further development became the standard IDLE now in use. The main goal was to make programming in Python as interactive for whole scripts as it is for single statements executed interactively in the shell. There are very good reasons to want novice programmers who are writing computational physics programs to be writing and running full programs at all times, not to be working at the statement level in the interactive shell. Interacting in the shell can of course be very useful for expert programmers, but this kind of interaction with a programming language weakens for our students the concept that a program is a complete sequence of operations, performed sequentially. It may sound strange, but this is not a trivial concept to many newcomers. (Another consideration is that it can be difficult while working in the shell for a novice to keep track of what the current state is, especially with respect to what modules are active; when you run complete programs, you're starting from scratch each time.) The key element for implementing this goal was single-keypress run/debug cycle, to make running a full program just as interactive as running a single statement in the shell. There are two things that can interfere with this goal: 1) If a dialog box intrudes between pressing F5 and seeing the program run, that is cognitively intrusive. It breaks into your thoughts in a way that is not conducive to concentrating on the problem. (Yes, you can instead teach people to press three keys, ctrl-S and then F5, but that's just plain more awkward and intrusive.) Our students write small programs, only a page or two long (thanks to the unusual properties of Python and VPython), and they make small edits many times per hour. The strong visual feedback of the 3D visualizations produced by VPython means that it makes sense to encourage students to run these small programs immediately after small edits rather than doing a lot of coding before ever running. Again, the point is to be able to program in a highly interactive way. For these reasons we deploy IDLE with its default options set to "No Prompt" and "Open Edit Window". 2) If time elapses between making a edit and seeing the change, that too is cognitively intrusive. An entirely natural modality when writing a VPython program is to run, leave the 3D graphics window open on the screen (possibly with an animation still proceeding) while making program edits to correct errors that are made manifest by the 3D display, then press F5 to (a) stop the old run and (b) start the new run. Imposing a time delay is intrusive. Or to put it another way, it is a wonderful experience to be able to make a small change and see its effect immediately. This gives the high single-keypress interactivity for full programming that otherwise is available only for single-statement shell operations. I should mention too that Dave built the VPython environment in such a way that when your Python code terminates (exit from a calculational loop, typically), the 3D graphics window stays alive for inspection (and rotate/zoom navigation with the mouse), which is precisely what one wants for the default behavior of the program. But then IDLE needs to kill that window instantly upon pressing F5 to run again (sometimes with no edits -- you often just want to see the animation again from the start). 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. Bruce Sherwood From dblank at brynmawr.edu Mon May 26 23:16:16 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon, 26 May 2008 17:16:16 -0400 (EDT) Subject: [Idle-dev] Fix for long delays In-Reply-To: <483AE025.9070004@ncsu.edu> References: <483AE025.9070004@ncsu.edu> Message-ID: <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> Hi, Bruce. I'm familiar with VPython and think it is great. It would be wonderful to get this kind of detailed feedback from real classroom use into IDLE. Your use of IDLE, like ours, required some similar changes. Perhaps Dave can list out, point by point, the changes the patch makes, and we can discuss those? I'd be in favor of IDLE instantly killing the shell on exit, and for making it generally more useful for VPython (and for us). In fact, I'm going to try the patch tonight to see if it would work for our uses too. Perhaps we can get rid of our hacks in favor of a general solution. (I think that Tal incorporated a version of F5 that only reloaded the module and didn't restart the shell. But I just downloaded Python2.5 for Windows and see that IDLE is still version 1.2.2 :( ) Thanks, -Doug On Mon, May 26, 2008 12:07 pm, Bruce Sherwood said: > 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. > > When Dave created VPython (vpython.org) in 2000, he also created a new version of IDLE which with further development became the standard IDLE now in use. The main goal was to make programming in Python as > interactive for whole scripts as it is for single statements executed interactively in the shell. There are very good reasons to want novice programmers who are writing computational physics programs to be writing and running full programs at all times, not to be working at the statement level in the interactive shell. Interacting in the shell can of course be very useful for expert programmers, but this kind of interaction with a programming language weakens for our students the concept that a program is a complete sequence of operations, performed sequentially. It may sound strange, but this is not a trivial concept to many newcomers. (Another consideration is that it can be difficult while working in the shell for a novice to keep track of what the current state is, especially with respect to what modules are active; when you run complete programs, you're starting from scratch each time.) > > The key element for implementing this goal was single-keypress run/debug cycle, to make running a full program just as interactive as running a single statement in the shell. There are two things that can interfere with this goal: > > 1) If a dialog box intrudes between pressing F5 and seeing the program run, that is cognitively intrusive. It breaks into your thoughts in a way that is not conducive to concentrating on the problem. (Yes, you can instead teach people to press three keys, ctrl-S and then F5, but that's just plain more awkward and intrusive.) Our students write small programs, only a page or two long (thanks to the unusual properties of Python and VPython), and they make small edits many times per hour. The strong visual feedback of the 3D visualizations produced by VPython means that it makes sense to encourage students to run these small programs immediately after small edits rather than doing a lot of coding before ever running. Again, the point is to be able to program in a highly interactive way. For these reasons we deploy IDLE with its default options set to "No Prompt" and "Open Edit Window". > > 2) If time elapses between making a edit and seeing the change, that too is cognitively intrusive. An entirely natural modality when writing a VPython program is to run, leave the 3D graphics window open on the screen (possibly with an animation still proceeding) while making program edits to correct errors that are made manifest by the 3D display, then press F5 to (a) stop the old run and (b) start the new run. Imposing a time delay is intrusive. Or to put it another way, it is a wonderful experience to be able to make a small change and see its effect immediately. This gives the high single-keypress interactivity for full programming that otherwise is available only for > single-statement shell operations. > > I should mention too that Dave built the VPython environment in such a way that when your Python code terminates (exit from a calculational loop, typically), the 3D graphics window stays alive for inspection (and rotate/zoom navigation with the mouse), which is precisely what one wants for the default behavior of the program. But then IDLE needs to kill that window instantly upon pressing F5 to run again (sometimes with no edits -- you often just want to see the animation again from the start). > > 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. > > Bruce Sherwood > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 From Bruce_Sherwood at ncsu.edu Tue May 27 00:36:05 2008 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Mon, 26 May 2008 16:36:05 -0600 Subject: [Idle-dev] Fix for long delays In-Reply-To: <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> References: <483AE025.9070004@ncsu.edu> <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> Message-ID: <483B3B55.5070307@ncsu.edu> An HTML attachment was scrubbed... URL: From dscherertemp at gmail.com Tue May 27 04:03:17 2008 From: dscherertemp at gmail.com (David Scherer) Date: Mon, 26 May 2008 22:03:17 -0400 Subject: [Idle-dev] Fix for long delays In-Reply-To: <41288ed40805261901s15520d19n1fb861a13b0af6ca@mail.gmail.com> References: <483AE025.9070004@ncsu.edu> <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> <41288ed40805261901s15520d19n1fb861a13b0af6ca@mail.gmail.com> Message-ID: <41288ed40805261903r21b75d3bw9f24678e030a480e@mail.gmail.com> Bruce: Thanks for correcting my earlier posting error! 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: Your use of IDLE, like ours, required some similar changes. Perhaps Dave > can list out, point by point, the changes the patch makes, and we can > discuss those? The patch is really very simple: when IDLE wants to terminate the subprocess, it uses the most direct and powerful command available from the operating system to do it, instead of asking the subprocess to terminate itself in a relatively unreliable way. This is the most straightforward, easy, efficient and elegant way to do the job. The only reason it's more than a couple of lines of code is because Python provides slightly different interfaces to do this on UNIX and Windows (reflecting the slightly different operating system APIs). I'd be in favor of IDLE instantly killing the shell on exit, and for > making it generally more useful for VPython (and for us). In fact, I'm > going to try the patch tonight to see if it would work for our uses too. > Perhaps we can get rid of our hacks in favor of a general solution. (I > think that Tal incorporated a version of F5 that only reloaded the module > and didn't restart the shell. But I just downloaded Python2.5 for Windows > and see that IDLE is still version 1.2.2 :( ) Restarting the shell is essential for us: it's impossible to reliably return a program to its initial state by any other method. It's one of the major advantages of the subprocess model. Please let us know how my patch works for you! Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dblank at brynmawr.edu Tue May 27 04:43:39 2008 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Mon, 26 May 2008 22:43:39 -0400 (EDT) Subject: [Idle-dev] Fix for long delays In-Reply-To: <41288ed40805261903r21b75d3bw9f24678e030a480e@mail.gmail.com> References: <483AE025.9070004@ncsu.edu> <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> <41288ed40805261901s15520d19n1fb861a13b0af6ca@mail.gmail.com> <41288ed40805261903r21b75d3bw9f24678e030a480e@mail.gmail.com> Message-ID: <52632.71.59.123.159.1211856219.squirrel@webmail.brynmawr.edu> Dave, Just tried it, and got this error under Linux: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'maxint'" in > ignored I had to adjust the patch a bit as it got mangled through the mailer (and I've attached the version to this email) so please check that I got it all. 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'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? 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. If we can get a working version of this patch, I'd vote for it. -Doug On Mon, May 26, 2008 10:03 pm, David Scherer said: > Bruce: Thanks for correcting my earlier posting error! 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: > > Your use of IDLE, like ours, required some similar changes. Perhaps Dave >> can list out, point by point, the changes the patch makes, and we can >> discuss those? > > > The patch is really very simple: when IDLE wants to terminate the > subprocess, it uses the most direct and powerful command available from > the > operating system to do it, instead of asking the subprocess to terminate > itself in a relatively unreliable way. This is the most straightforward, > easy, efficient and elegant way to do the job. The only reason it's more > than a couple of lines of code is because Python provides slightly > different > interfaces to do this on UNIX and Windows (reflecting the slightly > different > operating system APIs). > > I'd be in favor of IDLE instantly killing the shell on exit, and for >> making it generally more useful for VPython (and for us). In fact, I'm >> going to try the patch tonight to see if it would work for our uses too. >> Perhaps we can get rid of our hacks in favor of a general solution. (I >> think that Tal incorporated a version of F5 that only reloaded the >> module >> and didn't restart the shell. But I just downloaded Python2.5 for >> Windows >> and see that IDLE is still version 1.2.2 :( ) > > > Restarting the shell is essential for us: it's impossible to reliably > return > a program to its initial state by any other method. It's one of the major > advantages of the subprocess model. > > Please let us know how my patch works for you! > > Dave > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 -------------- next part -------------- A non-text attachment was scrubbed... Name: idle-kill.patch Type: text/x-patch Size: 2342 bytes Desc: not available URL: From taleinat at gmail.com Tue May 27 20:52:57 2008 From: taleinat at gmail.com (Tal Einat) Date: Tue, 27 May 2008 21:52:57 +0300 Subject: [Idle-dev] Fix for long delays In-Reply-To: <52632.71.59.123.159.1211856219.squirrel@webmail.brynmawr.edu> References: <483AE025.9070004@ncsu.edu> <49812.71.59.123.159.1211836576.squirrel@webmail.brynmawr.edu> <41288ed40805261901s15520d19n1fb861a13b0af6ca@mail.gmail.com> <41288ed40805261903r21b75d3bw9f24678e030a480e@mail.gmail.com> <52632.71.59.123.159.1211856219.squirrel@webmail.brynmawr.edu> Message-ID: <7afdee2f0805271152q76f0ae52ob29c5733d9fa6dff@mail.gmail.com> 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 From taleinat at gmail.com Tue May 27 21:07:54 2008 From: taleinat at gmail.com (Tal Einat) Date: Tue, 27 May 2008 22:07:54 +0300 Subject: [Idle-dev] Fix for long delays In-Reply-To: <40811.71.59.123.159.1211808629.squirrel@webmail.brynmawr.edu> References: <41288ed40805141448u4328e33ege0fd199f4e7b3b98@mail.gmail.com> <41288ed40805141515o5b559311k40995ba1f81551a3@mail.gmail.com> <7afdee2f0805260242n594e38d4v9ec0a1213c686b00@mail.gmail.com> <54362.71.59.123.159.1211803318.squirrel@webmail.brynmawr.edu> <7afdee2f0805260551l294a99bci5e5eea9d26ce7af9@mail.gmail.com> <40811.71.59.123.159.1211808629.squirrel@webmail.brynmawr.edu> Message-ID: <7afdee2f0805271207q344f441eo3f9de32684f6bae7@mail.gmail.com> Douglas S. Blank wrote: > On Mon, May 26, 2008 8:51 am, Tal Einat said: >> Douglas S. Blank wrote: >>> 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. That could be done, but it would require a major refactoring. IDLE is currently implemented with the idea of a single shell hard-coded throughout the code. For instance, IDLE's completion uses the shell's namespace to figure out possible completions. If there would be multiple shells, which one's namespace should be used? In which one would files be executed when you used Run Module (F5)? Also, implementing and maintaining a cross-platform method of having files opened in the same process could be difficult. To be clear -- I think this is a good idea, and I can understand the importance for teaching. I too have had learners stumble over these issues. I just think that it needs to be thought through and may require a lot of work. Hopefully with more support we can make things like this happen. - Tal