[Python-ideas] Smart/Curly Quote Marks and cPython

Terry Reedy tjreedy at udel.edu
Sat Oct 22 22:51:50 EDT 2016


On 10/22/2016 12:32 PM, Nick Coghlan wrote:
> On 22 October 2016 at 17:36, Ryan Birmingham <rainventions at 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



More information about the Python-ideas mailing list