[Python-Dev] SyntaxError for illegal literals

[Ka-Ping Yee]

I wrote:
> The strongest reason is that a long file with a typo in a string
> literal somewhere in hundreds of lines of code generates only
>
>     ValueError: invalid \x escape
> 
> with no indication to where the error is -- not even which file!

Thomas Wouters wrote:
> This has nothing to do with the error being a ValueError, but with some
> (compile-time) errors not being promoted to 'full' errors. See

I think they are entirely related.  All ValueErrors should be run-time
errors; a ValueError should never occur during compilation.  The key
issue is communicating clearly with the user, and that's just not what
ValueError *means*.

M.-A. Lemburg wrote:
> Right and I think this touches the core of the problem. SyntaxErrors
> produce a proper traceback while ValueErrors (and others) just print
> a single line which doesn't even have the filename or line number.

This follows sensibly from the fact that SyntaxErrors are always
compile-time errors (and therefore have no traceback or frame at the
level where the error occurred).  ValueErrors are usually run-time
errors, so .filename and .lineno attributes would be redundant;
this information is already available in the associated frame object.

> Perhaps lifting the restriction in PyErr_PrintEx() and making the
> parse_syntax_error() API a little more robust might do the trick.
> Then the various direct PyErr_SetString() calls in compile.c
> should be converted to use com_error() instead (if possible).

That sounds like a significant amount of work, and i'm not sure it's
the right answer.  If we just clarify the boundary by making sure
make sure that all, and only, compile-time errors are SyntaxErrors,
everything would work properly and the meaning of the various
exception classes would be clearer.  The only exceptions that don't
currently conform, as far as i know, have to do with invalid literals.


-- ?!ng