From ggpolo at gmail.com Tue Aug 4 15:25:07 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Tue, 4 Aug 2009 10:25:07 -0300 Subject: [Idle-dev] Merging VIDLE differences into idlelib Message-ID: Hi there, I have verified the VIDLE fork last week expecting to find many differences between it and IDLE. Most files differ but it turned out that most of these differences are equivalent (many of the changes were merged already), except for two of them. One of these changes is related to py2app, so I can't verify it. The second is about using the subprocess module to spawn the subprocess, so it is easier to terminate it properly under Windows (the original code was a bit different since it was done before Python 2.6). I'm not a heavy Windows so I can't tell how much this helps, my guess is that it would help with http://bugs.python.org/issue2708. Do anyone believe these changes could help IDLE ? Index: Lib/idlelib/PyShell.py =================================================================== --- Lib/idlelib/PyShell.py (revision 74191) +++ Lib/idlelib/PyShell.py (working copy) @@ -11,6 +11,7 @@ import threading import traceback import types +import subprocess import macosxSupport import linecache @@ -40,11 +41,6 @@ HOST = '127.0.0.1' # python execution server on localhost loopback PORT = 0 # someday pass in host, port for remote debug capability -try: - from signal import SIGTERM -except ImportError: - SIGTERM = 15 - # Override warnings module to write to warning_stream. Initialize to send IDLE # internal warnings to the console. ScriptBinding.check_syntax() will # temporarily redirect the stream to the shell window to display warnings when @@ -347,13 +343,13 @@ self.port = PORT rpcclt = None - rpcpid = None + rpcproc = None def spawn_subprocess(self): - if self.subprocess_arglist == None: + if self.subprocess_arglist is None: self.subprocess_arglist = self.build_subprocess_arglist() 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): assert (self.port!=0), ( @@ -433,7 +429,7 @@ pass # Kill subprocess, spawn a new one, accept connection. self.rpcclt.close() - self.unix_terminate() + self.terminate_subprocess() console = self.tkconsole was_executing = console.executing console.executing = False @@ -474,23 +470,14 @@ self.rpcclt.close() except AttributeError: # no socket pass - self.unix_terminate() + self.terminate_subprocess() self.tkconsole.executing = False self.rpcclt = None - 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 + def terminate_subprocess(self): + "Make sure subprocess is terminated and collect status." + self.rpcproc.kill() + self.rpcproc.wait() def transfer_path(self): self.runcommand("""if 1: @@ -1312,6 +1299,8 @@ def main(): global flist, root, use_subprocess + macosxSupport.preprocessArguments() + use_subprocess = True enable_shell = True enable_edit = False Index: Lib/idlelib/macosxSupport.py =================================================================== --- Lib/idlelib/macosxSupport.py (revision 74191) +++ Lib/idlelib/macosxSupport.py (working copy) @@ -9,7 +9,7 @@ """ Returns True if Python is running from within an app on OSX. If so, assume that Python was built with Aqua Tcl/Tk rather than - X11 Tck/Tk. + X11 Tcl/Tk. """ return (sys.platform == 'darwin' and '.app' in sys.executable) @@ -121,6 +121,13 @@ menu.add_command(label=label, underline=underline, command=command, accelerator=accelerator) +def preprocessArguments(): + # Deal with spurious argument passed by Finder, so "argv emulation" is + # not required for app bundle + argv = sys.argv + if runningAsOSXApp() and len(argv) > 1 and argv[1].startswith("-psn"): + del sys.argv[1] + def setupApp(root, flist): """ Perform setup for the OSX application bundle. -- -- Guilherme H. Polo Goncalves From nad at acm.org Tue Aug 4 19:55:24 2009 From: nad at acm.org (Ned Deily) Date: Tue, 04 Aug 2009 10:55:24 -0700 Subject: [Idle-dev] Merging VIDLE differences into idlelib References: Message-ID: In article , Guilherme Polo wrote: > I have verified the VIDLE fork last week expecting to find many > differences between it and IDLE. Most files differ but it turned out > that most of these differences are equivalent (many of the changes > were merged already), except for two of them. One of these changes is > related to py2app, so I can't verify it. [...] > Index: Lib/idlelib/macosxSupport.py > =================================================================== > --- Lib/idlelib/macosxSupport.py (revision 74191) > +++ Lib/idlelib/macosxSupport.py (working copy) > @@ -9,7 +9,7 @@ > """ > Returns True if Python is running from within an app on OSX. > If so, assume that Python was built with Aqua Tcl/Tk rather than > - X11 Tck/Tk. > + X11 Tcl/Tk. > """ > return (sys.platform == 'darwin' and '.app' in sys.executable) > > @@ -121,6 +121,13 @@ > menu.add_command(label=label, underline=underline, > command=command, accelerator=accelerator) > > +def preprocessArguments(): > + # Deal with spurious argument passed by Finder, so "argv emulation" is > + # not required for app bundle > + argv = sys.argv > + if runningAsOSXApp() and len(argv) > 1 and argv[1].startswith("-psn"): > + del sys.argv[1] > + > def setupApp(root, flist): > """ > Perform setup for the OSX application bundle. This isn't needed as there already is similar code in Mac/IDLE/idlemain.py, an initialization script that gets invoked when IDLE.app is launched and that goes on to call idlelib.Pyshell.main. (BTW, this has nothing to do with py2app which is not used by IDLE or anything else in the standard library.) -- Ned Deily, nad at acm.org From ggpolo at gmail.com Tue Aug 4 20:16:55 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Tue, 4 Aug 2009 15:16:55 -0300 Subject: [Idle-dev] Merging VIDLE differences into idlelib In-Reply-To: References: Message-ID: 2009/8/4 Ned Deily : > In article > , > ?Guilherme Polo wrote: >> I have verified the VIDLE fork last week expecting to find many >> differences between it and IDLE. Most files differ but it turned out >> that most of these differences are equivalent (many of the changes >> were merged already), except for two of them. One of these changes is >> related to py2app, so I can't verify it. > > [...] > >> Index: Lib/idlelib/macosxSupport.py >> =================================================================== >> --- Lib/idlelib/macosxSupport.py ? ? ?(revision 74191) >> +++ Lib/idlelib/macosxSupport.py ? ? ?(working copy) >> @@ -9,7 +9,7 @@ >> ? ? ?""" >> ? ? ?Returns True if Python is running from within an app on OSX. >> ? ? ?If so, assume that Python was built with Aqua Tcl/Tk rather than >> - ? ?X11 Tck/Tk. >> + ? ?X11 Tcl/Tk. >> ? ? ?""" >> ? ? ?return (sys.platform == 'darwin' and '.app' in sys.executable) >> >> @@ -121,6 +121,13 @@ >> ? ? ? ? ? ? ? ? ? ? ? ? ?menu.add_command(label=label, underline=underline, >> ? ? ? ? ? ? ? ? ? ? ? ? ?command=command, accelerator=accelerator) >> >> +def preprocessArguments(): >> + ? ?# Deal with spurious argument passed by Finder, so "argv emulation" is >> + ? ?# not required for app bundle >> + ? ?argv = sys.argv >> + ? ?if runningAsOSXApp() and len(argv) > 1 and argv[1].startswith("-psn"): >> + ? ? ? ?del sys.argv[1] >> + >> ?def setupApp(root, flist): >> ? ? ?""" >> ? ? ?Perform setup for the OSX application bundle. > > This isn't needed as there already is similar code in > Mac/IDLE/idlemain.py, an initialization script that gets invoked when > IDLE.app is launched and that goes on to call idlelib.Pyshell.main. > (BTW, this has nothing to do with py2app which is not used by IDLE or > anything else in the standard library.) > I'm aware of py2app not being used by IDLE (or anything else in std lib), but what prevents someone from running py2app on idlelib and getting an similar IDLE.app ? I'm really not into Mac, but isn't this IDLE.app just an bundle that could be similarly built with py2app ? Anyway, if the code for supporting argv emulation already exists then it is very fine to not include it. Thanks for your input, > -- > ?Ned Deily, > ?nad at acm.org > -- -- Guilherme H. Polo Goncalves From nad at acm.org Tue Aug 4 20:34:13 2009 From: nad at acm.org (Ned Deily) Date: Tue, 04 Aug 2009 11:34:13 -0700 Subject: [Idle-dev] Merging VIDLE differences into idlelib References: Message-ID: In article , Guilherme Polo wrote: > I'm aware of py2app not being used by IDLE (or anything else in std > lib), but what prevents someone from running py2app on idlelib and > getting an similar IDLE.app ? I'm really not into Mac, but isn't this > IDLE.app just an bundle that could be similarly built with py2app ? There's nothing preventing someone from trying to create their own variant of an IDLE.app but it's probably a bit tricky to get everything right even with py2app and, since the standard python.org OS X installers already provide two ways to launch IDLE (as an .app and from the command line), I don't see providing hooks in idlelib for yet another way as a significant use case. -- Ned Deily, nad at acm.org From ggpolo at gmail.com Mon Aug 17 15:01:33 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 10:01:33 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback Message-ID: Hello, These days I have been talking a lot with Bruce Sherwood, who is a great enthusiast about IDLE and has watched large numbers of novice users of IDLE, and several ideas have been proposed and are now implemented on a branch living on svn.python.org. Some of the changes were proposed by David Scherer, who created the modern idlefork in the year 2000. I would like to see most or all of the changes merged into Python and here I am hoping I can get some feedback. Below are the ideas that have been implemented recently in the context of part of a Google Summer of Code project: * Allow running code without explicitly saving it before. This has been added in such way to allow the default settings to preserve the current behaviour. In this case when an exception occurs, the temporary file name is substituted by "Untitled" on the traceback. At some point, this option was available in the 2000 idlefork and has been sorely missed by those users who prefer to write little test routines in an edit window rather than in the shell window; without this capability it is distracting to have to choose a place to save a test file. Upon exit from IDLE the user is asked whether to save the file permanently. * Bring IDLE's shell forward on first thing printed to sys.stderr, this can only happen again after a shell restart. I consider this of great importance when writing programs that may open other windows, like a Tkinter program, or a Visual one, since the user might expect something to happen on that window but nothing happens because of an error that occurred without him noticing. As reported by Bruce, the lack of this feature has been a big problem in courses where novices write such programs and don't understand why an animation has stopped, because the error message is behind other windows. * Terminate the server process under Windows too. On python trunk this is done only for platforms that support os.kill. * On python trunk when IDLE is configured to open an edit window, it also opens a shell window. This has been reverted to behave as users had come to expect, and because having the shell window present when it is not in use can be distracting to novices working in environments where they start in an edit window. * When printing a traceback, highlight the stack traces that pertain to the running file and also remove the "in " from them. This is an attempt to make easier for novices to spot probable errors in their own code.Highlight here simply means that it is written to stderr, like it is done now, and the other parts are printed to stdout. The effect normally is that, by default, errors in the primary file are displayed in red, and other call stack information is blue. * Now "View Last Restart" shows the last non-empty instance of a shell restart. In some cases a VPython application may cause two shell restarts, one of them being after all application's output and thus "View Last Restart" would be of no use if it moved the view to this empty restart. If you would like to try the branch, please do a svn checkout of http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ It also includes some other fixes and new features not mentioned above. Thanks, -- -- Guilherme H. Polo Goncalves From fuzzyman at voidspace.org.uk Mon Aug 17 15:11:04 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 17 Aug 2009 14:11:04 +0100 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: References: Message-ID: <4A8956E8.8060008@voidspace.org.uk> Guilherme Polo wrote: > Hello, > > These days I have been talking a lot with Bruce Sherwood, who is a > great enthusiast about IDLE and has watched large numbers of novice > users of IDLE, and several ideas have been proposed and are now > implemented on a branch living on svn.python.org. Some of the changes > were proposed by David Scherer, who created the modern idlefork in the > year 2000. I would like to see most or all of the changes merged into > Python and here I am hoping I can get some feedback. > > Below are the ideas that have been implemented recently in the context > of part of a Google Summer of Code project: > > * Allow running code without explicitly saving it before. This has > been added in such way to allow the default settings to preserve the > current behaviour. In this case when an exception occurs, the > temporary file name is substituted by "Untitled" on the traceback. At > some point, this option was available in the 2000 idlefork and has > been sorely missed by those users who prefer to write little test > routines in an edit window rather than in the shell window; without > this capability it is distracting to have to choose a place to save a > test file. Upon exit from IDLE the user is asked whether to save the > file permanently. > +1 (or more if I could) > * Bring IDLE's shell forward on first thing printed to sys.stderr, > this can only happen again after a shell restart. I consider this of > great importance when writing programs that may open other windows, > like a Tkinter program, or a Visual one, since the user might expect > something to happen on that window but nothing happens because of an > error that occurred without him noticing. As reported by Bruce, the > lack of this feature has been a big problem in courses where novices > write such programs and don't understand why an animation has stopped, > because the error message is behind other windows. > > -0 (doesn't this mean having to *constantly* move the window out of the way when your logging code causes it to jump in front of your GUI) > * Terminate the server process under Windows too. On python trunk this > is done only for platforms that support os.kill. > +1 > * On python trunk when IDLE is configured to open an edit window, it > also opens a shell window. This has been reverted to behave as users > had come to expect, and because having the shell window present when > it is not in use can be distracting to novices working in environments > where they start in an edit window. > > -0 (the shell windows is useful!) > * When printing a traceback, highlight the stack traces that pertain > to the running file and also remove the "in " from them. This > is an attempt to make easier for novices to spot probable errors in > their own code.Highlight here simply means that it is written to > stderr, like it is done now, and the other parts are printed to > stdout. The effect normally is that, by default, errors in the primary > file are displayed in red, and other call stack information is blue. > > +0 (I haven't noticed this problem but will take your word for it) > * Now "View Last Restart" shows the last non-empty instance of a shell > restart. In some cases a VPython application may cause two shell > restarts, one of them being after all application's output and thus > "View Last Restart" would be of no use if it moved the view to this > empty restart. > > +0 > If you would like to try the branch, please do a svn checkout of > http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ > It also includes some other fixes and new features not mentioned above. > > I'll give it a try. Unfortunately IDLE on the Mac is not very good looking (a Tk problem rather than an IDLE problem I think) which means I have less motivation to use it since I left Windows as my main dev environment. Michael > Thanks, > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From ggpolo at gmail.com Mon Aug 17 15:27:33 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 10:27:33 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A8956E8.8060008@voidspace.org.uk> References: <4A8956E8.8060008@voidspace.org.uk> Message-ID: 2009/8/17 Michael Foord : > Guilherme Polo wrote: >> * Bring IDLE's shell forward on first thing printed to sys.stderr, >> this can only happen again after a shell restart. I consider this of >> great importance when writing programs that may open other windows, >> like a Tkinter program, or a Visual one, since the user might expect >> something to happen on that window but nothing happens because of an >> error that occurred without him noticing. As reported by Bruce, the >> lack of this feature has been a big problem in courses where novices >> write such programs and don't understand why an animation has stopped, >> because the error message is behind other windows. >> >> > > -0 ?(doesn't this mean having to *constantly* move the window out of the way > when your logging code causes it to jump in front of your GUI) Depending on the level of the logging, yes but only the first time. If you do, for instance, logging.error('buh') followed by many others, just the first call would bring the window forward. I have considered making this optional too, since it is very likely that some people won't like this supposed distraction even if it is telling about some possible error. > >> * Terminate the server process under Windows too. On python trunk this >> is done only for platforms that support os.kill. >> > > +1 >> >> * On python trunk when IDLE is configured to open an edit window, it >> also opens a shell window. This has been reverted to behave as users >> had come to expect, and because having the shell window present when >> it is not in use can be distracting to novices working in environments >> where they start in an edit window. >> >> > > -0 (the shell windows is useful!) > >> * When printing a traceback, highlight the stack traces that pertain >> to the running file and also remove the "in " from them. This >> is an attempt to make easier for novices to spot probable errors in >> their own code.Highlight here simply means that it is written to >> stderr, like it is done now, and the other parts are printed to >> stdout. The effect normally is that, by default, errors in the primary >> file are displayed in red, and other call stack information is blue. >> >> > > +0 (I haven't noticed this problem but will take your word for it) > >> * Now "View Last Restart" shows the last non-empty instance of a shell >> restart. In some cases a VPython application may cause two shell >> restarts, one of them being after all application's output and thus >> "View Last Restart" would be of no use if it moved the view to this >> empty restart. >> >> > > +0 > > >> If you would like to try the branch, please do a svn checkout of >> http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ >> It also includes some other fixes and new features not mentioned above. >> >> > > I'll give it a try. Thanks by commenting so fast, totally unexpected from my part. Btw, as you will probably notice, or already noticed, I pasted the url to view the repository online. If someone want to do a read-only checkout, the /view/ in the url has to be replaced by /projects/. > Unfortunately IDLE on the Mac is not very good looking > (a Tk problem rather than an IDLE problem I think) which means I have less > motivation to use it since I left Windows as my main dev environment. > I understand. Doesn't ttk widgets improve anything there ? I don't have a mac and I rarely see a mac, so I really don't know how it looks like there. IDLE isn't using ttk widgets, but last year I did something that would use them when available so it could be worth the effort to adapt it to the current IDLE code. > Michael > Regards, -- -- Guilherme H. Polo Goncalves From fuzzyman at voidspace.org.uk Mon Aug 17 15:38:04 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 17 Aug 2009 14:38:04 +0100 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: References: <4A8956E8.8060008@voidspace.org.uk> Message-ID: <4A895D3C.1060204@voidspace.org.uk> Guilherme Polo wrote: > [snip...] >> Unfortunately IDLE on the Mac is not very good looking >> (a Tk problem rather than an IDLE problem I think) which means I have less >> motivation to use it since I left Windows as my main dev environment. >> >> > > I understand. Doesn't ttk widgets improve anything there ? I don't > have a mac and I rarely see a mac, so I really don't know how it looks > like there. IDLE isn't using ttk widgets, but last year I did > something that would use them when available so it could be worth the > effort to adapt it to the current IDLE code. > > I think that in principle ttk would help, but doesn't Python ship its *own* version of Tk *or* use the system Tk - neither of which have ttk available. I'm nothing like a Tk expert, but if there are instructions on how to try then I can give it a go. If you have the code then I can do some research (as and when I have time). All the best, Michael >> Michael >> >> > > Regards, > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From ggpolo at gmail.com Mon Aug 17 15:44:38 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 10:44:38 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A895D3C.1060204@voidspace.org.uk> References: <4A8956E8.8060008@voidspace.org.uk> <4A895D3C.1060204@voidspace.org.uk> Message-ID: 2009/8/17 Michael Foord : > Guilherme Polo wrote: >> >> [snip...] >>> >>> Unfortunately IDLE on the Mac is not very good looking >>> (a Tk problem rather than an IDLE problem I think) which means I have >>> less >>> motivation to use it since I left Windows as my main dev environment. >>> >>> >> >> I understand. Doesn't ttk widgets improve anything there ? I don't >> have a mac and I rarely see a mac, so I really don't know how it looks >> like there. IDLE isn't using ttk widgets, but last year I did >> something that would use them when available so it could be worth the >> effort to adapt it to the current IDLE code. >> >> > > I think that in principle ttk would help, but doesn't Python ship its *own* > version of Tk *or* use the system Tk - neither of which have ttk available. > If the system Tk version is 8.5 or newer then ttk is included, otherwise you need to install tile. > I'm nothing like a Tk expert, but if there are instructions on how to try > then I can give it a go. If you have the code then I can do some research > (as and when I have time). > If you have ttk available, there are some demos on Demo/tkinter/ttk/. Running them should be enough to see if there is some difference on the appearance or not. Or, if you want the code that changes IDLE a bit, you can grab it from: http://code.google.com/p/python-ttk/downloads/list Screenshots (for fun) can be found at http://code.google.com/p/python-ttk/wiki/Screenshots > All the best, > > Michael >>> >>> Michael >>> >>> >> >> Regards, >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > -- -- Guilherme H. Polo Goncalves From taleinat at gmail.com Mon Aug 17 15:55:00 2009 From: taleinat at gmail.com (Tal Einat) Date: Mon, 17 Aug 2009 16:55:00 +0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A8956E8.8060008@voidspace.org.uk> References: <4A8956E8.8060008@voidspace.org.uk> Message-ID: <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> Michael Foord wrote: > Guilherme Polo wrote: >> >> * Allow running code without explicitly saving it before. This has >> been added in such way to allow the default settings to preserve the >> current behaviour. In this case when an exception occurs, the >> temporary file name is substituted by "Untitled" on the traceback. At >> some point, this option was available in the 2000 idlefork and has >> been sorely missed by those users who prefer to write little test >> routines in an edit window rather than in the shell window; without >> this capability it is distracting to have to choose a place to save a >> test file. Upon exit from IDLE the user is asked whether to save the >> file permanently. > > +1 (or more if I could) +1 as well >> * Bring IDLE's shell forward on first thing printed to sys.stderr, >> this can only happen again after a shell restart. I consider this of >> great importance when writing programs that may open other windows, >> like a Tkinter program, or a Visual one, since the user might expect >> something to happen on that window but nothing happens because of an >> error that occurred without him noticing. As reported by Bruce, the >> lack of this feature has been a big problem in courses where novices >> write such programs and don't understand why an animation has stopped, >> because the error message is behind other windows. > > -0 ?(doesn't this mean having to *constantly* move the window out of the way > when your logging code causes it to jump in front of your GUI) ... which would teach users to only log actual errors to stderr. +1 >> * Terminate the server process under Windows too. On python trunk this >> is done only for platforms that support os.kill. > > +1 +1 (wasn't such a patch already submitted to the issue tracker?) >> >> * On python trunk when IDLE is configured to open an edit window, it >> also opens a shell window. This has been reverted to behave as users >> had come to expect, and because having the shell window present when >> it is not in use can be distracting to novices working in environments >> where they start in an edit window. > > -0 (the shell windows is useful!) The shell is useful, but it's annoying to have to close/minimize it when you just want to read a file or make a minor edit. Having the shell pop up is especially unexpected when using the "Edit with IDLE" Windows context menu option. The shell can always be opened with Run->Shell. +1 >> * When printing a traceback, highlight the stack traces that pertain >> to the running file and also remove the "in " from them. This >> is an attempt to make easier for novices to spot probable errors in >> their own code.Highlight here simply means that it is written to >> stderr, like it is done now, and the other parts are printed to >> stdout. The effect normally is that, by default, errors in the primary >> file are displayed in red, and other call stack information is blue. > > +0 (I haven't noticed this problem but will take your word for it) I'm a big fan of the Squeezer IDLE extension, and this would break Squeezer's recognition of blocks of output / tracebacks. Such (ab)use of sys.stdout and sys.stderr is too much of a hack IMHO. -1 >> * Now "View Last Restart" shows the last non-empty instance of a shell >> restart. In some cases a VPython application may cause two shell >> restarts, one of them being after all application's output and thus >> "View Last Restart" would be of no use if it moved the view to this >> empty restart. > > +0 +0 as well, I've never used "view last restart" myself. >> If you would like to try the branch, please do a svn checkout of >> http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ >> It also includes some other fixes and new features not mentioned above. I'll definitely give it a go, hopefully tonight or tomorrow after work. - Tal From fuzzyman at voidspace.org.uk Mon Aug 17 16:02:46 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 17 Aug 2009 15:02:46 +0100 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> Message-ID: <4A896306.5070207@voidspace.org.uk> Tal Einat wrote: > [snip...] > >>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>> this can only happen again after a shell restart. I consider this of >>> great importance when writing programs that may open other windows, >>> like a Tkinter program, or a Visual one, since the user might expect >>> something to happen on that window but nothing happens because of an >>> error that occurred without him noticing. As reported by Bruce, the >>> lack of this feature has been a big problem in courses where novices >>> write such programs and don't understand why an animation has stopped, >>> because the error message is behind other windows. >>> >> -0 (doesn't this mean having to *constantly* move the window out of the way >> when your logging code causes it to jump in front of your GUI) >> > > ... which would teach users to only log actual errors to stderr. > +1 > > Really? Even in libraries they didn't write? Deliberately pissing off users, even in the name of teaching them good habits, is never a good strategy. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From ggpolo at gmail.com Mon Aug 17 16:04:40 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 11:04:40 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> Message-ID: 2009/8/17 Tal Einat : > Michael Foord wrote: >> Guilherme Polo wrote: >>> * Terminate the server process under Windows too. On python trunk this >>> is done only for platforms that support os.kill. >> >> +1 > > +1 (wasn't such a patch already submitted to the issue tracker?) > I'm not sure about that, maybe I missed it. >>> * When printing a traceback, highlight the stack traces that pertain >>> to the running file and also remove the "in " from them. This >>> is an attempt to make easier for novices to spot probable errors in >>> their own code.Highlight here simply means that it is written to >>> stderr, like it is done now, and the other parts are printed to >>> stdout. The effect normally is that, by default, errors in the primary >>> file are displayed in red, and other call stack information is blue. >> >> +0 (I haven't noticed this problem but will take your word for it) > > I'm a big fan of the Squeezer IDLE extension, and this would break > Squeezer's recognition of blocks of output / tracebacks. Such (ab)use > of sys.stdout and sys.stderr is too much of a hack IMHO. > > -1 > I see, I definitively need to take a look into Squeezer. It seems to solve several issues reported on bugs.python.org. >>> If you would like to try the branch, please do a svn checkout of >>> http://svn.python.org/view/python/branches/tk_and_idle_maintenance/ >>> It also includes some other fixes and new features not mentioned above. > > I'll definitely give it a go, hopefully tonight or tomorrow after work. > Thanks Tal, I appreciate it. > - Tal > -- -- Guilherme H. Polo Goncalves From ggpolo at gmail.com Mon Aug 17 16:13:05 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 11:13:05 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A896306.5070207@voidspace.org.uk> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A896306.5070207@voidspace.org.uk> Message-ID: 2009/8/17 Michael Foord : > Tal Einat wrote: >> >> [snip...] >> >>>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>>> this can only happen again after a shell restart. I consider this of >>>> great importance when writing programs that may open other windows, >>>> like a Tkinter program, or a Visual one, since the user might expect >>>> something to happen on that window but nothing happens because of an >>>> error that occurred without him noticing. As reported by Bruce, the >>>> lack of this feature has been a big problem in courses where novices >>>> write such programs and don't understand why an animation has stopped, >>>> because the error message is behind other windows. >>>> >>> >>> -0 ?(doesn't this mean having to *constantly* move the window out of the >>> way >>> when your logging code causes it to jump in front of your GUI) >>> >> >> ... which would teach users to only log actual errors to stderr. >> +1 >> >> > > Really? Even in libraries they didn't write? > > Deliberately pissing off users, even in the name of teaching them good > habits, is never a good strategy. > I have no doubt this is a feature that might help some and annoy others. I still stand on my opinion that it is a good addition, but making it optional seems really the better way to go. > Michael > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > -- -- Guilherme H. Polo Goncalves From taleinat at gmail.com Mon Aug 17 16:17:10 2009 From: taleinat at gmail.com (Tal Einat) Date: Mon, 17 Aug 2009 17:17:10 +0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> Message-ID: <7afdee2f0908170717r34d202f0rdac3577c3ea4efa@mail.gmail.com> Guilherme Polo wrote: > 2009/8/17 Tal Einat : >> Michael Foord wrote: >>> Guilherme Polo wrote: >>>> * Terminate the server process under Windows too. On python trunk this >>>> is done only for platforms that support os.kill. >>> >>> +1 >> >> +1 (wasn't such a patch already submitted to the issue tracker?) >> > > I'm not sure about that, maybe I missed it. Silly me, I was referring to the patch which you yourself mailed to idle-dev a short while ago. I assume the changes in that patch are incorporated in your new branch. - Tal From ggpolo at gmail.com Mon Aug 17 16:25:38 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 11:25:38 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <7afdee2f0908170717r34d202f0rdac3577c3ea4efa@mail.gmail.com> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <7afdee2f0908170717r34d202f0rdac3577c3ea4efa@mail.gmail.com> Message-ID: 2009/8/17 Tal Einat : > Guilherme Polo wrote: >> 2009/8/17 Tal Einat : >>> Michael Foord wrote: >>>> Guilherme Polo wrote: >>>>> * Terminate the server process under Windows too. On python trunk this >>>>> is done only for platforms that support os.kill. >>>> >>>> +1 >>> >>> +1 (wasn't such a patch already submitted to the issue tracker?) >>> >> >> I'm not sure about that, maybe I missed it. > > Silly me, I was referring to the patch which you yourself mailed to > idle-dev a short while ago. I assume the changes in that patch are > incorporated in your new branch. > Yes, but that patch received some adjusts. One of the changes is that now it ignores WindowsError when killing the process, and I've also removed the proposed new function on macosxSupport.py as it was suggested that is it not required. > - Tal > -- -- Guilherme H. Polo Goncalves From ggpolo at gmail.com Mon Aug 17 21:05:42 2009 From: ggpolo at gmail.com (Guilherme Polo) Date: Mon, 17 Aug 2009 16:05:42 -0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A896306.5070207@voidspace.org.uk> Message-ID: 2009/8/17 Guilherme Polo : > 2009/8/17 Michael Foord : >> Tal Einat wrote: >>> >>> [snip...] >>> >>>>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>>>> this can only happen again after a shell restart. I consider this of >>>>> great importance when writing programs that may open other windows, >>>>> like a Tkinter program, or a Visual one, since the user might expect >>>>> something to happen on that window but nothing happens because of an >>>>> error that occurred without him noticing. As reported by Bruce, the >>>>> lack of this feature has been a big problem in courses where novices >>>>> write such programs and don't understand why an animation has stopped, >>>>> because the error message is behind other windows. >>>>> >>>> >>>> -0 ?(doesn't this mean having to *constantly* move the window out of the >>>> way >>>> when your logging code causes it to jump in front of your GUI) >>>> >>> >>> ... which would teach users to only log actual errors to stderr. >>> +1 >>> >>> >> >> Really? Even in libraries they didn't write? >> >> Deliberately pissing off users, even in the name of teaching them good >> habits, is never a good strategy. >> > > I have no doubt this is a feature that might help some and annoy > others. I still stand on my opinion that it is a good addition, but > making it optional seems really the better way to go. It is now "officially" an option, defaulting to bring shell forward on first error. -- -- Guilherme H. Polo Goncalves From Bruce_Sherwood at ncsu.edu Tue Aug 18 02:44:30 2009 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Mon, 17 Aug 2009 20:44:30 -0400 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A896306.5070207@voidspace.org.uk> Message-ID: <4A89F96E.306@ncsu.edu> I don't have a problem with it being an option to have the error window come forward, and we can argue about what the default should be. But I'd like to explain in some depth how extremely important this is in certain environments. Ruth Chabay and I have developed an alternative curriculum for the introductory physics course taken by engineering and science students in their first and/or second year in the university (see http://www.matterandinteractions.org). This new curriculum emphasizes a 20th-century perspective on introductory physics, in stark contrast to the 19th-century perspective that has been traditional for over 50 years. One of the implications is that computational modeling plays an important role in the curriculum, with students writing Python programs to model physical systems (actually, VPython, a 3D programming environment; see vpython.org). This is a vitally important innovation, because computational modeling is now central to all engineering and science but has hardly penetrated the undergraduate curriculum. Almost all of these students are very knowledgeable in the use of computers except for one type of use: programming. So every semester there are thousands of students writing VPython programs despite having no previous programming experience. This is feasible thanks to the cleanliness of Python, and the fact that we need teach only a very small subset of the language, just sufficient for our purposes, and to the fact that VPython generates navigable 3D animations as a side effect of computations. These novices need all the help the environment can give. A continual major problem is that a student will stare without comprehension at a halted animation without realizing that the halt is due to a program error, because the shell window is hidden behind the animation window. It is really really really important for the shell window to come forward when there is an error. Thanks to those who have responded to Guilherme's summary of new features, it is evident that there may be sophisticated users who would be inconvenienced by this change, so it makes sense for it to be an option. I would argue strongly that the default should be to bring the shell window forward, as Guilherme has now implemented, because the sophisticated user can deal with the issue, whereas the novice user is unlikely even to look at the configuration options in IDLE. Bruce Sherwood Guilherme Polo wrote: > 2009/8/17 Guilherme Polo : >> 2009/8/17 Michael Foord : >>> Tal Einat wrote: >>>> [snip...] >>>> >>>>>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>>>>> this can only happen again after a shell restart. I consider this of >>>>>> great importance when writing programs that may open other windows, >>>>>> like a Tkinter program, or a Visual one, since the user might expect >>>>>> something to happen on that window but nothing happens because of an >>>>>> error that occurred without him noticing. As reported by Bruce, the >>>>>> lack of this feature has been a big problem in courses where novices >>>>>> write such programs and don't understand why an animation has stopped, >>>>>> because the error message is behind other windows. >>>>>> >>>>> -0 (doesn't this mean having to *constantly* move the window out of the >>>>> way >>>>> when your logging code causes it to jump in front of your GUI) >>>>> >>>> ... which would teach users to only log actual errors to stderr. >>>> +1 >>>> >>>> >>> Really? Even in libraries they didn't write? >>> >>> Deliberately pissing off users, even in the name of teaching them good >>> habits, is never a good strategy. >>> >> I have no doubt this is a feature that might help some and annoy >> others. I still stand on my opinion that it is a good addition, but >> making it optional seems really the better way to go. > > It is now "officially" an option, defaulting to bring shell forward on > first error. > > From fuzzyman at voidspace.org.uk Tue Aug 18 11:21:05 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 18 Aug 2009 10:21:05 +0100 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A89F96E.306@ncsu.edu> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A896306.5070207@voidspace.org.uk> <4A89F96E.306@ncsu.edu> Message-ID: <4A8A7281.1020109@voidspace.org.uk> Bruce Sherwood wrote: > I don't have a problem with it being an option to have the error > window come forward, and we can argue about what the default should > be. But I'd like to explain in some depth how extremely important this > is in certain environments. For the record, if it only happens the first time I have no problem with it being on by default. My earlier response was only in the context of the reply that annoying users was no problem as it would teach them a lesson. All the best, Michael Foord > > Ruth Chabay and I have developed an alternative curriculum for the > introductory physics course taken by engineering and science students > in their first and/or second year in the university (see > http://www.matterandinteractions.org). This new curriculum emphasizes > a 20th-century perspective on introductory physics, in stark contrast > to the 19th-century perspective that has been traditional for over 50 > years. One of the implications is that computational modeling plays an > important role in the curriculum, with students writing Python > programs to model physical systems (actually, VPython, a 3D > programming environment; see vpython.org). This is a vitally important > innovation, because computational modeling is now central to all > engineering and science but has hardly penetrated the undergraduate > curriculum. > > Almost all of these students are very knowledgeable in the use of > computers except for one type of use: programming. So every semester > there are thousands of students writing VPython programs despite > having no previous programming experience. This is feasible thanks to > the cleanliness of Python, and the fact that we need teach only a very > small subset of the language, just sufficient for our purposes, and to > the fact that VPython generates navigable 3D animations as a side > effect of computations. > > These novices need all the help the environment can give. A continual > major problem is that a student will stare without comprehension at a > halted animation without realizing that the halt is due to a program > error, because the shell window is hidden behind the animation window. > It is really really really important for the shell window to come > forward when there is an error. > > Thanks to those who have responded to Guilherme's summary of new > features, it is evident that there may be sophisticated users who > would be inconvenienced by this change, so it makes sense for it to be > an option. I would argue strongly that the default should be to bring > the shell window forward, as Guilherme has now implemented, because > the sophisticated user can deal with the issue, whereas the novice > user is unlikely even to look at the configuration options in IDLE. > > Bruce Sherwood > > Guilherme Polo wrote: >> 2009/8/17 Guilherme Polo : >>> 2009/8/17 Michael Foord : >>>> Tal Einat wrote: >>>>> [snip...] >>>>> >>>>>>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>>>>>> this can only happen again after a shell restart. I consider >>>>>>> this of >>>>>>> great importance when writing programs that may open other windows, >>>>>>> like a Tkinter program, or a Visual one, since the user might >>>>>>> expect >>>>>>> something to happen on that window but nothing happens because >>>>>>> of an >>>>>>> error that occurred without him noticing. As reported by Bruce, the >>>>>>> lack of this feature has been a big problem in courses where >>>>>>> novices >>>>>>> write such programs and don't understand why an animation has >>>>>>> stopped, >>>>>>> because the error message is behind other windows. >>>>>>> >>>>>> -0 (doesn't this mean having to *constantly* move the window out >>>>>> of the >>>>>> way >>>>>> when your logging code causes it to jump in front of your GUI) >>>>>> >>>>> ... which would teach users to only log actual errors to stderr. >>>>> +1 >>>>> >>>>> >>>> Really? Even in libraries they didn't write? >>>> >>>> Deliberately pissing off users, even in the name of teaching them good >>>> habits, is never a good strategy. >>>> >>> I have no doubt this is a feature that might help some and annoy >>> others. I still stand on my opinion that it is a good addition, but >>> making it optional seems really the better way to go. >> >> It is now "officially" an option, defaulting to bring shell forward on >> first error. >> >> > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev -- http://www.ironpythoninaction.com/ From Bruce_Sherwood at ncsu.edu Tue Aug 18 17:36:02 2009 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Tue, 18 Aug 2009 11:36:02 -0400 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A8A7281.1020109@voidspace.org.uk> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A896306.5070207@voidspace.org.uk> <4A89F96E.306@ncsu.edu> <4A8A7281.1020109@voidspace.org.uk> Message-ID: <4A8ACA62.2060909@ncsu.edu> Thanks for the clarification! And my own lengthy response wasn't intended to be argumentative, only to explain the context within which this feature is highly important. It's possible that this context is one of the largest deployments of Python (and IDLE) with people who have no programming experience. Bruce Sherwood Michael Foord wrote: > Bruce Sherwood wrote: >> I don't have a problem with it being an option to have the error >> window come forward, and we can argue about what the default should >> be. But I'd like to explain in some depth how extremely important this >> is in certain environments. > > For the record, if it only happens the first time I have no problem with > it being on by default. My earlier response was only in the context of > the reply that annoying users was no problem as it would teach them a > lesson. > > All the best, > > Michael Foord > >> >> Ruth Chabay and I have developed an alternative curriculum for the >> introductory physics course taken by engineering and science students >> in their first and/or second year in the university (see >> http://www.matterandinteractions.org). This new curriculum emphasizes >> a 20th-century perspective on introductory physics, in stark contrast >> to the 19th-century perspective that has been traditional for over 50 >> years. One of the implications is that computational modeling plays an >> important role in the curriculum, with students writing Python >> programs to model physical systems (actually, VPython, a 3D >> programming environment; see vpython.org). This is a vitally important >> innovation, because computational modeling is now central to all >> engineering and science but has hardly penetrated the undergraduate >> curriculum. >> >> Almost all of these students are very knowledgeable in the use of >> computers except for one type of use: programming. So every semester >> there are thousands of students writing VPython programs despite >> having no previous programming experience. This is feasible thanks to >> the cleanliness of Python, and the fact that we need teach only a very >> small subset of the language, just sufficient for our purposes, and to >> the fact that VPython generates navigable 3D animations as a side >> effect of computations. >> >> These novices need all the help the environment can give. A continual >> major problem is that a student will stare without comprehension at a >> halted animation without realizing that the halt is due to a program >> error, because the shell window is hidden behind the animation window. >> It is really really really important for the shell window to come >> forward when there is an error. >> >> Thanks to those who have responded to Guilherme's summary of new >> features, it is evident that there may be sophisticated users who >> would be inconvenienced by this change, so it makes sense for it to be >> an option. I would argue strongly that the default should be to bring >> the shell window forward, as Guilherme has now implemented, because >> the sophisticated user can deal with the issue, whereas the novice >> user is unlikely even to look at the configuration options in IDLE. >> >> Bruce Sherwood >> >> Guilherme Polo wrote: >>> 2009/8/17 Guilherme Polo : >>>> 2009/8/17 Michael Foord : >>>>> Tal Einat wrote: >>>>>> [snip...] >>>>>> >>>>>>>> * Bring IDLE's shell forward on first thing printed to sys.stderr, >>>>>>>> this can only happen again after a shell restart. I consider >>>>>>>> this of >>>>>>>> great importance when writing programs that may open other windows, >>>>>>>> like a Tkinter program, or a Visual one, since the user might >>>>>>>> expect >>>>>>>> something to happen on that window but nothing happens because >>>>>>>> of an >>>>>>>> error that occurred without him noticing. As reported by Bruce, the >>>>>>>> lack of this feature has been a big problem in courses where >>>>>>>> novices >>>>>>>> write such programs and don't understand why an animation has >>>>>>>> stopped, >>>>>>>> because the error message is behind other windows. >>>>>>>> >>>>>>> -0 (doesn't this mean having to *constantly* move the window out >>>>>>> of the >>>>>>> way >>>>>>> when your logging code causes it to jump in front of your GUI) >>>>>>> >>>>>> ... which would teach users to only log actual errors to stderr. >>>>>> +1 >>>>>> >>>>>> >>>>> Really? Even in libraries they didn't write? >>>>> >>>>> Deliberately pissing off users, even in the name of teaching them good >>>>> habits, is never a good strategy. >>>>> >>>> I have no doubt this is a feature that might help some and annoy >>>> others. I still stand on my opinion that it is a good addition, but >>>> making it optional seems really the better way to go. >>> >>> It is now "officially" an option, defaulting to bring shell forward on >>> first error. >>> >>> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev > > From Bruce_Sherwood at ncsu.edu Wed Aug 19 04:30:22 2009 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Tue, 18 Aug 2009 22:30:22 -0400 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> Message-ID: <4A8B63BE.7090804@ncsu.edu> Tal Einat wrote: >>> * When printing a traceback, highlight the stack traces that pertain >>> to the running file and also remove the "in " from them. This >>> is an attempt to make easier for novices to spot probable errors in >>> their own code.Highlight here simply means that it is written to >>> stderr, like it is done now, and the other parts are printed to >>> stdout. The effect normally is that, by default, errors in the primary >>> file are displayed in red, and other call stack information is blue. >> +0 (I haven't noticed this problem but will take your word for it) > > I'm a big fan of the Squeezer IDLE extension, and this would break > Squeezer's recognition of blocks of output / tracebacks. Such (ab)use > of sys.stdout and sys.stderr is too much of a hack IMHO. > > -1 Could you say a bit more about what Squeezer is or does? How would this colorization affect Squeezer? Bruce Sherwood From Bruce_Sherwood at ncsu.edu Thu Aug 20 23:49:05 2009 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Thu, 20 Aug 2009 17:49:05 -0400 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <7afdee2f0908201326q42299bb5ka6d7a45d2e95ded8@mail.gmail.com> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A8B63BE.7090804@ncsu.edu> <7afdee2f0908201326q42299bb5ka6d7a45d2e95ded8@mail.gmail.com> Message-ID: <4A8DC4D1.8030006@ncsu.edu> Thanks, but I can't visualize what problem the proposed call stack reporting would raise in the Squeezer context....? Wouldn't stuff be squeezed or not just the same? Bruce Tal Einat wrote: > Bruce Sherwood wrote: >> Tal Einat wrote: >>>>> * When printing a traceback, highlight the stack traces that pertain >>>>> to the running file and also remove the "in " from them. This >>>>> is an attempt to make easier for novices to spot probable errors in >>>>> their own code.Highlight here simply means that it is written to >>>>> stderr, like it is done now, and the other parts are printed to >>>>> stdout. The effect normally is that, by default, errors in the primary >>>>> file are displayed in red, and other call stack information is blue. >>>> +0 (I haven't noticed this problem but will take your word for it) >>> I'm a big fan of the Squeezer IDLE extension, and this would break >>> Squeezer's recognition of blocks of output / tracebacks. Such (ab)use >>> of sys.stdout and sys.stderr is too much of a hack IMHO. >>> >>> -1 >> Could you say a bit more about what Squeezer is or does? How would this >> colorization affect Squeezer? > > The Squeezer[1] extension for IDLE avoids having IDLE slow down or > hang when large amounts of text are printed in the shell. > > Technically, Squeezer can replace any block of output (either stdout > or stderr) with a button. This button can be expanded back to the > original text, or it can be used to view the squeezed text in a > separate window or copy it to the clipboard. When a large amount of > output is written at once to the output, squeezer automatically > inserts a "squeezed" button instead without ever printing the output, > thus saving the interactive session from doom. One can also manually > squeeze blocks of output and blocks of stderr output such as > tracebacks. > > A picture is worth a thousand words, so I'm attaching a screenshot I > just worked up in my IDLE. > > - Tal > > [1] http://pypi.python.org/pypi/Squeezer/1.0 > > > ------------------------------------------------------------------------ > From taleinat at gmail.com Thu Aug 20 22:26:17 2009 From: taleinat at gmail.com (Tal Einat) Date: Thu, 20 Aug 2009 23:26:17 +0300 Subject: [Idle-dev] Some implemented ideas that may help IDLE, request for feedback In-Reply-To: <4A8B63BE.7090804@ncsu.edu> References: <4A8956E8.8060008@voidspace.org.uk> <7afdee2f0908170655i2119febbr5503850e9fb05929@mail.gmail.com> <4A8B63BE.7090804@ncsu.edu> Message-ID: <7afdee2f0908201326q42299bb5ka6d7a45d2e95ded8@mail.gmail.com> Bruce Sherwood wrote: > Tal Einat wrote: >>>> >>>> * When printing a traceback, highlight the stack traces that pertain >>>> to the running file and also remove the "in " from them. This >>>> is an attempt to make easier for novices to spot probable errors in >>>> their own code.Highlight here simply means that it is written to >>>> stderr, like it is done now, and the other parts are printed to >>>> stdout. The effect normally is that, by default, errors in the primary >>>> file are displayed in red, and other call stack information is blue. >>> >>> +0 (I haven't noticed this problem but will take your word for it) >> >> I'm a big fan of the Squeezer IDLE extension, and this would break >> Squeezer's recognition of blocks of output / tracebacks. Such (ab)use >> of sys.stdout and sys.stderr is too much of a hack IMHO. >> >> -1 > > Could you say a bit more about what Squeezer is or does? How would this > colorization affect Squeezer? The Squeezer[1] extension for IDLE avoids having IDLE slow down or hang when large amounts of text are printed in the shell. Technically, Squeezer can replace any block of output (either stdout or stderr) with a button. This button can be expanded back to the original text, or it can be used to view the squeezed text in a separate window or copy it to the clipboard. When a large amount of output is written at once to the output, squeezer automatically inserts a "squeezed" button instead without ever printing the output, thus saving the interactive session from doom. One can also manually squeeze blocks of output and blocks of stderr output such as tracebacks. A picture is worth a thousand words, so I'm attaching a screenshot I just worked up in my IDLE. - Tal [1] http://pypi.python.org/pypi/Squeezer/1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: Squeezer.JPG Type: image/jpeg Size: 117885 bytes Desc: not available URL: