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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4