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!