[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!