On 1/24/2019 5:52 PM, Chris Angelico wrote:
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.
It would be a change if the code is never called. I'm not sure we care
about code that's never called, but it is a change.
Eric
_______________________________________________
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
