[Python-Dev] Add more SyntaxWarnings?
Chris Angelico
rosuav at gmail.com
Thu Jan 24 17:52:53 EST 2019
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano <steve at 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.
More information about the Python-Dev
mailing list