Dave Scherer suggested that I join this discussion, as I represent a
constituency of literally thousands of college students who use IDLE in
intro physics classes at a number of major universities (I'm also a
developer of VPython). Let me offer an explanation of goals, somewhat
independent of implementation issues.
When Dave created VPython (vpython.org) in 2000, he also created a new
version of IDLE which with further development became the standard IDLE
now in use. The main goal was to make programming in Python as
interactive for whole scripts as it is for single statements executed
interactively in the shell. There are very good reasons to want novice
programmers who are writing computational physics programs to be writing
and running full programs at all times, not to be working at the
statement level in the interactive shell. Interacting in the shell can
of course be very useful for expert programmers, but this kind of
interaction with a programming language weakens for our students the
concept that a program is a complete sequence of operations, performed
sequentially. It may sound strange, but this is not a trivial concept to
many newcomers. (Another consideration is that it can be difficult while
working in the shell for a novice to keep track of what the current
state is, especially with respect to what modules are active; when you
run complete programs, you're starting from scratch each time.)
The key element for implementing this goal was single-keypress run/debug
cycle, to make running a full program just as interactive as running a
single statement in the shell. There are two things that can interfere
with this goal:
1) If a dialog box intrudes between pressing F5 and seeing the program
run, that is cognitively intrusive. It breaks into your thoughts in a
way that is not conducive to concentrating on the problem. (Yes, you can
instead teach people to press three keys, ctrl-S and then F5, but that's
just plain more awkward and intrusive.) Our students write small
programs, only a page or two long (thanks to the unusual properties of
Python and VPython), and they make small edits many times per hour. The
strong visual feedback of the 3D visualizations produced by VPython
means that it makes sense to encourage students to run these small
programs immediately after small edits rather than doing a lot of coding
before ever running. Again, the point is to be able to program in a
highly interactive way. For these reasons we deploy IDLE with its
default options set to "No Prompt" and "Open Edit Window".
2) If time elapses between making a edit and seeing the change, that too
is cognitively intrusive. An entirely natural modality when writing a
VPython program is to run, leave the 3D graphics window open on the
screen (possibly with an animation still proceeding) while making
program edits to correct errors that are made manifest by the 3D
display, then press F5 to (a) stop the old run and (b) start the new
run. Imposing a time delay is intrusive. Or to put it another way, it is
a wonderful experience to be able to make a small change and see its
effect immediately. This gives the high single-keypress interactivity
for full programming that otherwise is available only for
single-statement shell operations.
I should mention too that Dave built the VPython environment in such a
way that when your Python code terminates (exit from a calculational
loop, typically), the 3D graphics window stays alive for inspection (and
rotate/zoom navigation with the mouse), which is precisely what one
wants for the default behavior of the program. But then IDLE needs to
kill that window instantly upon pressing F5 to run again (sometimes with
no edits -- you often just want to see the animation again from the start).
Some time ago, there was some change to IDLE that had the very
unfortunate effect of leaving an old graphics window on the screen when
you pressed F5 to run again, with the result that the more times you
ran, the more old graphics windows cluttered up the screen. When Dave
became active again in VPython development, he realized what the problem
was, and that was his original motivation for patching IDLE. In the
process he also identified some related problems, which his patch addresses.
Bruce Sherwood
_______________________________________________
IDLE-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/idle-dev
