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

[David Scherer]

> 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.

Good!

> Of course, reverse
> execution is also complicated in the face of I/O and other externally
> visible side-effects.

A way to reverse all side-effects of an arbitrary program would be great.
If you get it working, I think it would be really useful for things other
than just Python programming (un-send e-mail, un-crash Windows... :)

Maybe Guido intends to release the source code for this time machine I keep
hearing about?

>   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.)

This is already being discussed in another thread.  I don't have a complete
design to offer.  I have suggested a scrolling output window which when the
program starts scrolls to hide the results of previous runs, e.g.:

|  Hello, world!
|
|  Hello, world!
|  My program now prints two lines.
|
|  -------------- Top of window (but you can scroll up past here)
|  Hello, world!
|  The following line is a quine:
|  'is not a quine' is not a quine

That alone might suffice to keep the window count reasonable in our
environment.  We will be disabling the "Python Shell" window by default, and
most of our students will only be editing a single file containing their
program, which leaves just one editor window and one persistent output
window, plus any graphics windows the program creates.

> 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.

I realize that it isn't easy.  I don't know how feasable it is to get more
useful diagnostics out of the Python parser, but in the worst case we can at
least implement a few heuristics.  We will attempt to collect some
unscientific data on the most commonly encountered errors, but unmatched
delimiters and missing ":"s seem very common.

> 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.

I did a terrible job of explaining this, partly because I've been using
several different versions of IDLE, including some of my own hacks, and I
can't remember which ones do what anymore :)  Let me just start over from a
slightly different perspective.

Tracebacks are useful to experienced programmers debugging complex
applications with deep call stacks.  It is likely that one of the functions
along the call stack is responsible for causing an exception, but which one
might not be clear.  Dumping the entire stack allows the programmer to
decide.

For a novice programmer writing a simple program calling complex libraries,
the traceback is not so useful:

|Traceback (innermost last):
|  File "C:\python\Tools\idle_old\ScriptBinding.py",
|line 131, in run_module_event
|    execfile(filename, mod.__dict__)
|  File "C:\python\box.py", line 7, in ?
|    print s.posiiton
|  File "visual\prim.py", line 42, in __getattr__
|AttributeError: posiiton

Part of the problem here is something I mentioned before: the traceback
extends both "upwards" into IDLE's code and "downwards" into a library that
should be opaque to the programmer.  Removing that part would yield just:

|Traceback (innermost last):
|  File "C:\python\box.py", line 7, in ?
|    print s.posiiton
|AttributeError: posiiton

Then you can right-click on the 2nd line and choose "Go to file/line" from a
context menu, at which point you see the code highlighted in your editor
window.  Unfortunately, there is nothing to suggest to the user that they
can or should right-click on that particular line.  This interface is also
unlike anything students are likely to have seen before, and it's
unnecessarily cumbersome as well.

A better solution is to directly highlight the error in the editor window
and move the focus there.  The innermost line outside the system modules (in
my example, the only such line) is by far the best place to start.  The
error message itself also needs to be displayed somewhere in that window.

It might then be best to limit the display in the output window to just
"AttributeError: position".  The user can see the full call stack in the
debugger, which also gives them other context information, such as the
values of local variables.  Our students will have the debugger disabled,
and won't see a call stack at all, which is fine because they will be
writing very "flat" programs.

We have encountered some other issues with error reporting.  For example,
errors are incorrectly reported on the first line of some multi-line
expressions.  However, discussing these would require concrete examples
which I don't have handy.  I'll try to collect some and follow up later.

Dave