[Python-ideas] Better error messages [was: (no subject)]

[Stephen J. Turnbull]

victor rajewski writes:

 >    - I personally find the current error messages quite useful, and
 >    they have the advantage of being machine-parseable, so that IDEs
 >    such as PyCharm can add value to them. However, the audience of
 >    this idea is not me, and probably not you. It is students who
 >    are learning Python, and probably haven't done any programming
 >    at all. But it might also be casual programmers who never really
 >    look at error message as they are too computer-y.

That's a misconception.  You have not yet given up on a change to the
Python interpreter, so the audience is *every* user of the Python
interpreter (including other programs), and that's why you're getting
pushback.  The Python interpreter's main job is to execute code.  A
secondary job is provide *accurate* diagnostics of errors in
execution.  Interpreting those diagnostics is somebody else's job,
typically the programmer's.  For experienced programmers, that's
usually what you want, because (1) the interpretation is frequently
data-dependent and (2) the "obvious" suggestion may be wrong.

FYI, a *lot* of effort has gone into making error messages more
precise, more accurate, and more informative, eg, by improving stack
traces.

OTOH, if the diagnostics are accurate and machine-parsable, then the
amount of annoying detail that needs to be dealt with in providing a
"tutorial" front-end for those messages is small.  That suggests to me
that the problem really is that interpreting errors, even in "student"
programs, is *hard* and rules of thumb are frequently mistaken.
That's an excellent tradeoff if there's a teacher looking over the
(student) programmer's shoulder.  Not a good idea for the interpreter.

 >    - I'm not suggesting this should become part of the normal
 >    operation of Python, particularly if that breaks compatibility
 >    or impacts performance. A switch, or a seperate executable would
 >    probably work. I'd lean against the idea of tying this to a
 >    particular IDE/environment, but if that's the way this can
 >    progress, then let's do that to get it moving.

It really should be a separate executable.  There are multiple
implementations of Python, and even restricted to CPython, with even a
small amount of uptake this project will move a *lot* faster than
CPython does.  Every tiny change to the "better living through better
errors" database makes a difference to all the students out there, so
its release cycle should probably be really fast.

 >    - The examples listed in my original email are simply ideas,
 >    without much thought about how feasible (or useful) they are to
 >    implement. Going forward, we would identify common errors that
 >    beginners make, and what would help them fix these errors.

In other words, you envision a long-term project with an ongoing level
of effort.  I think that it's worth doing.  But I also think it's
quite feasible to put it in a separate project, with cooperation from
Python-Dev in the matter of ensuring that diagnostics are machine-
parseable.  Eg, this means that Python-Dev should not randomly change
messages that are necessary to interpret an Exception, and in some
cases it may be useful to add Exception/Error subtypes to make
interpretation more precise (though this will often get pushback).