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

[Jeremy Hylton]

>>>>> "DS" == David Scherer <dscherer@cmu.edu> writes:

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

It certainly sounds like there is an opportunity to share concepts and
code here.  Many of the requirements you have for a development
environment are ones we want to see in IDLE anyway.

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

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

This is an essential feature for program development, too!  There are
far too many opportunities to corrupt the program being developed or
IDLE itself when the user program runs in the IDLE process.  It's
useful to be able to open up a shell and run several programs in it or
to open up a shell that is in the IDLE process, but both of these are
expert features.

  DS> 2.  Interactive mode is not very important to us, at least for
  DS> now.  

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

We've actually thought some about implementing a reversible debugger
that would let you step forwards or backwards.  It's not a high
priority item for us, because it will be a lot of work to implement.
The basic approach people have taken to reverse debugging is to back
up by re-running the program but not as far.  To make this efficient,
you need to be able to checkpoint the process periodically.
Checkpointing seems to be the chief stumbling block; there is no
simple, portable approach that I'm aware of.  Of course, reverse
execution is also complicated in the face of I/O and other externally
visible side-effects.

  DS> 3.  Given that students will be writing all of their code in the
  DS> editor rather than the interactive window, and that we wish to
  DS> encourage a highly iterative development process, it is
  DS> important that the process of running programs from the editor
  DS> be as streamlined as possible.  Ideally, editing a program
  DS> should be as subjectively responsive as interactive mode.  One
  DS> keystroke to execute a program is better than two or three.

Absolutely.  The current interface for running programs is clumsy and
confusing.  There are too many keystrokes, and there is no clear
feedback that the program has been run.

  DS> Program output needs to be organized on the screen so that
  DS> students don't need to change focus or play whack-a-mole with
  DS> output windows.  It needs to be easy to terminate a program.

Can you say a little more about what you are interested in?  I imagine
you want multiple "buffers" to be displayed in a single window.  IDLE
doesn't support that yet, but I think it needs to.  (I was using IDLE
for some programming over the weekend and quickly ended up with a
dozen editor windows plus shells, grep output, etc.  "whack-a-mole" is
an excellent description.)

  DS> 5.  Error reporting is *very* important.

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

What is the difference you are referring to?  If I get a SyntaxError,
the shell window shows the following output:

>>> 
  File "/tmp/fact.py", line 2
    if (= n 0):
        ^
SyntaxError: invalid syntax

I can right-click on the 'File ...' line and it will jump to that
location in the editor window.

Other exceptions produce much the same output.

  DS>  - Highlighting the offending source code is a must.  The right
  DS> code, or a superset, always needs to be highlighted.  Something
  DS> 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

Not sure what this example is supposed to show.  What is the error?
Why are the two lines identical?

It's clear that the showing the code that caused the exception is
a requirement.  I'm just not sure how it fails to do that currently.
I'm not saying that it never fails; I'm just not sure how.

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

Yes.

  DS>  - Error messages need to be as specific and clear as possible.
  DS> Lots of the messages currently returned by Python and its
  DS> libraries could stand to be rewritten with the novice programmer
  DS> in mind.  

Yes.

  DS>           More precise identification of syntactical errors
  DS> would also be very helpful - "Missing )" is much better than
  DS> just "Syntax error".

It's not trivial to determine what the cause of the syntax error was.
It would be a nice feature, but the approach seems involved and mostly
ad hoc.

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

Cross-platform support is important for IDLE, too.  One of its target
audiences is educators and students, where the Mac is still a common
platform.  I don't do an Macintosh development, though; perhaps Guido
can say more about what the Tk/Tkinter issues are.

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

Sure.

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

I believe Guido intends to use an unshared copy of Tcl/Tk for future
Python releases as well.

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

The current Python install script is a Wise installer.  Again, I don't
know much about how this works.  Hopefully, Guido will chime in here,
too.

Jeremy