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 <ggp...@gmail.com>:
2009/8/17 Michael Foord <fuzzy...@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.
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev
