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

Guilherme Polo ggpolo at gmail.com
Mon Aug 17 15:27:33 CEST 2009

2009/8/17 Michael Foord <fuzzyman at voidspace.org.uk>:
> 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 <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)
>> * 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


-- Guilherme H. Polo Goncalves

More information about the IDLE-dev mailing list