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). _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
