On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano <st...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com