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