On 1/24/2019 5:52 PM, Chris Angelico wrote:
> 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.
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4