[Python-Dev] Add more SyntaxWarnings?
Eric V. Smith
eric at trueblade.com
Thu Jan 24 18:16:32 EST 2019
More information about the Python-Dev mailing list
Thu Jan 24 18:16:32 EST 2019
- Previous message (by thread): [Python-Dev] Add more SyntaxWarnings?
- Next message (by thread): [Python-Dev] Add more SyntaxWarnings?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Add more SyntaxWarnings?
- Next message (by thread): [Python-Dev] Add more SyntaxWarnings?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list