[Idle-dev] Fix for long delays

[Douglas S. Blank]

Hi, Bruce. I'm familiar with VPython and think it is great. It would be
wonderful to get this kind of detailed feedback from real classroom use
into IDLE.

Your use of IDLE, like ours, required some similar changes. Perhaps Dave
can list out, point by point, the changes the patch makes, and we can
discuss those?

I'd be in favor of IDLE instantly killing the shell on exit, and for
making it generally more useful for VPython (and for us). In fact, I'm
going to try the patch tonight to see if it would work for our uses too.
Perhaps we can get rid of our hacks in favor of a general solution. (I
think that Tal incorporated a version of F5 that only reloaded the module
and didn't restart the shell. But I just downloaded Python2.5 for Windows
and see that IDLE is still version 1.2.2 :( )

Thanks,

-Doug

On Mon, May 26, 2008 12:07 pm, Bruce Sherwood said:
> 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
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>


-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501