On Thu, Jan 24, 2019 at 2:55 PM Chris Angelico <rosuav@gmail.com> wrote:
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.
I'm -1 on all of these cases. There's nothing mysterious about e.g. `TypeError: unsupported operand type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated tuples. (Surely people get errors about int+str all the time, and they've never complained -- unlike the tuple tuple case.)
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"?
I don't think there's a *general* problem to be solved here.
ChrisA
[1] Yes, I know about XKCD 1172, but if someone's saying "if shouldnt_happen: None[None]" then that's their problem.
-- --Guido van Rossum (python.org/~guido)