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

[Guido van Rossum]

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

We intend to do this.

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

Try enabling "auto-open stack viewer" in the debug menu.  (This would
be better of course with the system parts of the traceback removed.)
This gives a BIG hint what to do!  (And yes, it's still a prototype.
Suggestions are welcome.  Note that you can edit variables here!
Eventually the stack view in the debugger should look the same.)

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

The logistics of this get tricky though...  If you put the message in
the status bar, it isn't very obvious, and a dialog makes it hard to
correlate it to the source 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.

That would be great!

Unfortunately, for better diagnostics we may have to completely redo
the parser...  So it will be an expensive project.  But I agree it's
needed.

--Guido van Rossum (home page: http://www.python.org/~guido/)