[Python-Dev] SyntaxError for illegal literals

Thomas Wouters thomas@xs4all.net
Wed, 14 Feb 2001 00:57:16 +0100


On Tue, Feb 13, 2001 at 03:11:10PM -0800, Ka-Ping Yee 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!
> I realize this could be hacked upon and fixed, but i think it points
> to a general inconsistency that ought to be considered and addressed.

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

https://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470

The same issue came up when importing modules that did 'from foo import *'
in a function scope.

>     1.  SyntaxErrors are for compile-time errors.  A problem with
>         a literal happens before the program starts running, and
>         it is useful for me, as the programmer, to know whether
>         the error occurred because of some computational process,
>         possibly depending on inputs, or whether it's a permanent
>         mistake that's literally in my source code.  In other words,
>         will a debugger do me any good?

Agreed. That could possibly be solved by a better description of the
valueerrors in question, though. (The 'invalid \x escape' message seems
pretty obvious a compiletime-error to me, but others might not.)

>     2.  SyntaxErrors pinpoint the exact location of the problem.
>         In principle, an error is a SyntaxError if and only if you
>         can point to an exact character position as being the cause
>         of the problem.

See above.

>     3.  A ValueError means "i got a value that wasn't allowed or
>         expected here".  That is not at all what is happening.
>         There is *no* defined value at all.  It's not that there
>         was a value and it was wrong -- the value was never even
>         brought into existence.

Not quite true. It wasn't *compiled*, but it's a literal, so it does exist.
The problem is not the value of a compiled \x escape, but the value after
the \x. 

>     4.  The current implementation of ValueErrors is very unhelpful
>         about what to do about an invalid literal, as explained
>         in the example above.  A SyntaxError would be much more useful.

See #1 :)

> I hope you will agree with me that solving only #4 by changing
> ValueErrors so they behave a little more like SyntaxErrors in
> certain particular situations isn't the best solution.

I don't, really. The name 'ValueError' is exactly right: what is wrong (in
the \x escape example) is the *value* of something (of the \x escape in
question.) If a syntax error was raised, I would think something was wrong
with the syntax. But the \x is placed in the right spot, inside a string
literal. The string literal itself is placed right. Why would it be a syntax
error ?

> In fact, i bet switching to SyntaxError would actually make some code
> of the form "try: eval ... except SyntaxError" work better, since the
> single except clause would catch all possible compilation problems
> with the input to eval.

I'd say you want a 'CompilerError' superclass instead. 

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!