[Idle-dev] Some implemented ideas that may help IDLE, request for feedback

Tal Einat taleinat at gmail.com
Mon Aug 17 15:55:00 CEST 2009

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.

>> * 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


>> * When printing a traceback, highlight the stack traces that pertain
>> to the running file and also remove the "in <module>" 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.


>> * 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

More information about the IDLE-dev mailing list