On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano <steve@pearwood.info> wrote:
We could say that implementations are allowed to raise errors at compile time instead of run time, but aren't required to. Then it becomes a matter of "quality of implementation".
For literal ints, strings, None, etc we can tell at compile time that an error will occur. All of these cannot fail to raise (short of changing the interpreter, in which case you're not using Python anymore):
1 + "1" # raises TypeError None[x] # TypeError 1.234(x) # TypeError "spam".idnex("a") # AttributeError
In these specific cases, there is nothing wrong with the *syntax*, but a compiler should be permitted to immediately raise the same exception that would otherwise occur at run time. This is a form of peephole optimization, I guess.
+1. If it's something that the peephole optimizer is already allowed to change (eg "1"+"1" is constant-folded) and there is absolutely no way that it can ever be changed at run time, then raising at compile time can't hurt [1]. It'd be as implementation-dependent and version-dependent as the peephole optimizer itself. Does there need to be a new subclass of SyntaxError for "Technically Valid But Not Meaningful" problems? Is there value in distinguishing "InevitableTypeError" from "InevitableAttributeError"? ChrisA [1] Yes, I know about XKCD 1172, but if someone's saying "if shouldnt_happen: None[None]" then that's their problem.