[Idle-dev] What we need, and how we can help

[David Scherer]

Hi, all.

Let me start with a brief introduction.  I'm an undergraduate at Carnegie
Mellon University, and I'm working with several other students and faculty
members to develop a visualization library for Python and deploy it in the
physics curriculum here.  Two of my collaborators, Bruce Sherwood and Ruth
Chabay, currently teach a two-semester introductory physics sequence called
"Matter and Interactions," in which students write graphical simulations of
physical processes in a language called cT.  We think that a Python-based
environment could be both easier to use and more powerful for this purpose.

The goal is to teach physics, not programming.  At present, only two days
out of the year are devoted to teaching students (a large minority of whom
have never programmed before) to use the language and environment.  This
sets an extremely high standard for the ease of use of every component of
the system.

We plan to put a significant amount of effort into bringing a development
environment to that level.  If the evolution of IDLE can dovetail with our
needs, as we believe it can, then we will be happy to contribute to IDLE.
If not, we would still like to share as much concept and code as possible.

Here's what we think we need.  Some of this fits in with what Guido has
already said about the future of IDLE, and some of it reflects a difference
in focus.  We are, of course, content to have features in our environment
that are unimportant to us, so long as they can be configured to be
unobtrusive.

1.  The IDE *must* be stable in the face of any correct or incorrect user
program (e.g. infinite loops, access to Tcl/Tk and the window system, etc.).
The user program also needs to start in a fresh interpreter so that its
behavior cannot be affected by previous runs.  Given the complexities of
shared access to libraries, this almost certainly means a separate OS
process for the user program.  We have prototyped a simple IDLE extension
that runs programs this way, but it does not yet permit adequate error
reporting or debugging.

2.  Interactive mode is not very important to us, at least for now.  As
attractive as the instant feedback it offers seems, there are serious
problems with it for our purposes.  For example:

 - It is impossible to reverse changes.  When a student makes a mistake in
an editor environment, pressing "undo" a few times and re-running the
program suffices to correct it.  In interactive mode there is no obvious way
to reverse actions which had side effects on the environment.  At present
there isn't even an easy way to start over.

 - It is hard to work with loops.  Many of the programs our students will be
writing are simulations in which the bulk of the code is inside a single,
large loop.  The user must type in the entire loop at once, which is
difficult and sacrifices all the advantages of interactive mode.

3.  Given that students will be writing all of their code in the editor
rather than the interactive window, and that we wish to encourage a highly
iterative development process, it is important that the process of running
programs from the editor be as streamlined as possible.  Ideally, editing a
program should be as subjectively responsive as interactive mode.  One
keystroke to execute a program is better than two or three.  Program output
needs to be organized on the screen so that students don't need to change
focus or play whack-a-mole with output windows.  It needs to be easy to
terminate a program.

4.  We do not expect to make much use of the debugger.  Physics simulations
are difficult to debug by single-stepping, because many steps are often
necessary before errors become apparent.  If the debugger cannot provide a
very large benefit to students, we don't have time to teach it.  Instead, we
plan to add inspection capabilities to our visualization library.

5.  Error reporting is *very* important.

 - Syntax errors and exceptions should be presented in the same way even
though they are reported through different mechanisms.

 - Highlighting the offending source code is a must.  The right code, or a
superset, always needs to be highlighted.  Something as simple as the
following can really confuse a novice:

line((1,2),(3,4)   # error is here
line((1,2),(3,4))  # but is reported on this line

 - Tracebacks should not by default extend into "system" modules, even if
those modules are implemented in Python.  Exactly how the IDE decides what
is a system module depends on whether and how it supports projects.
Anything that is open in an editor window or part of the current project is
not a system module.

 - Error messages need to be as specific and clear as possible.  Lots of the
messages currently returned by Python and its libraries could stand to be
rewritten with the novice programmer in mind.  More precise identification
of syntactical errors would also be very helpful - "Missing )" is much
better than just "Syntax error".

6.  Cross-platform support is important.  Windows, Unix, and Macintosh all
need to be supported.  The latter is obviously most difficult.  IDLE can
easily be made to start on the Mac, but there are serious stability problems
with Tkinter.  We are investigating those, but any advice would be
appreciated.

7.  We plan to distribute a single installer to students in the course (and
to anyone else who is interested), which will include Python, our
visualization library, an IDE that suits our needs, and all the libraries
such as Numeric and Tcl/Tk which the first three components require.

  - We will make synchronized releases for all platforms if possible.

  - We have developed a prototype Windows installer which differs from the
standard Python installer in several important ways, including integrating
an *unshared* copy of Tcl/Tk.  We believe it will reduce the number of
installation problems significantly.

  - If Python and IDLE are adopted in education on any scale, many other
people will want to roll their own distributions for similar reasons.  The
process could be streamlined considerably - for example, by making the
source for existing installers available.  Another issue which bears
consideration is how multiple distributions should coexist on the same
machine.

Dave Scherer