On 10/22/2016 12:32 PM, Nick Coghlan wrote:
On 22 October 2016 at 17:36, Ryan Birmingham <rainventi...@gmail.com> wrote:
Per the comments in this thread, I believe that a better error message for
this case would be a reasonable way to fix the use case around this issue.
It can be difficult to notice that your quotes are curved if you don't know
that's what you're looking for.
Looking for particular Unicode confusables when post-processing
SyntaxErrors seems like a reasonable idea to me - that's how we ended
up implementing the heuristic that reports "Missing parenthesis in
call to print" when folks attempt to run Python 2 code under Python 3.
At the moment, tokenizer and parser errors are some of the most
beginner-hostile ones we offer, since we don't have any real context
when raising them - it's just a naive algorithm saying "This isn't the
text I expected to see next". By contrast, later in the code
generation pipeline, we have more information about what the user was
trying to do, and can usually offer better errors.
What Guido pointed out when I was working on the "print" heuristic is
that we actually get a second go at this: the *exception constructor*
usually has access to the text that the tokenizer or parser couldn't
handle, and since it isn't on the critical performance path for
anything, we can afford to invest some time in looking for common
kinds of errors and try to nudge folks in a better direction when we
think they've tripped over one of them.
(Continuing my response to Steven saying "improved error messages ...
(especially in IDLE)")
IDLE compiles()s and exec()s user code within separate try-except
blocks, the latter usually being in a separate processes. Runtime
tracebacks and exceptions are sent back to IDLE's Shell to be printed
just as in a console (except for colorizing). Compile errors are
handled differently. Tracebacks are tossed after extracting the file,
line, and column (the last from the ^ marker). The latter are used to
tag text with a red background. For shell input, the exception is
printed normally. For editor input, it is displayed in a messagebox
over the editor window.
My point is that IDLE already intercepts exceptions and, for
SyntaxErrors, does simple modifications (hopefully enhancements) *in
Python*. So it could be an easy place to prototype, in Python, more
advanced enhancements. Experimental enhancements could be made
optional, and could supplement rather than replace the original message.
They could also be added and modified in bugfix releases.
I will say more about explaining exceptions better in another post.
--
Terry Jan Reedy
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
