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

Bruce Sherwood Bruce_Sherwood at ncsu.edu
Tue Aug 18 02:44:30 CEST 2009

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 <ggpolo at gmail.com>:
>> 2009/8/17 Michael Foord <fuzzyman at 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.
>> 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.

More information about the IDLE-dev mailing list