Repository navigation
[syntax-errors] Improve error message and range for pre-PEP-614 decorator syntax errors - #16581
Conversation
08badbb to
63e2de2
Compare
|
|
@ntBre and I discussed this and we deliberately decided against it because:
I'm not opposed to this change. I just want to make clear that we deliberately decided against it because we wanted to focus our time on higher priority syntax errors and reduce complexity |
| 3 | @await bar | ||
| | ^^^^^^^^^ Syntax Error: Cannot use `await` expression outside function-call arguments in a decorator on Python 3.8 (syntax was added in Python 3.9) |
There was a problem hiding this comment.
I actually find the "outside function-call arguments in a decorator" part a bit confusing because it made me think that this is only allowed in function-call arguments. I'd possibly remove it and keep it simply "Cannot use await expression in a decorator on Python 3.8 ..." but then the message cannot be used in a general way because, in this example, the await expression is only not allowed at the top-level (@(await x)) while @decorator(await x) would be ok.
There was a problem hiding this comment.
Oh, I see. So you interpreted "outside function-call arguments" as meaning "If I add parentheses, it will be valid syntax"?
Hmm, I'm not sure how to clarify that :/ adding the parentheses doesn't make it a function call -- but I can see how a beginner might find the language confusing. Would you find "outside call expression arguments" any clearer?
There was a problem hiding this comment.
Sorry for the late reply, what I thought it could be interpreted is related to the function that's being decorated and not the decorator itself. But, I think what you've is fine as well. We can iterate if anyone finds it confusing.
b034baf to
4158b95
Compare
* main: (25 commits) [syntax-errors] Parenthesized context managers before Python 3.9 (#16523) [ci]: Disable wheel testing on `ppc64le` (#16793) [red-knot] Stabilize `negation_reverses_subtype_order` property test (#16801) [red-knot] Emit error if int/float/complex/bytes/boolean literals appear in type expressions outside `typing.Literal[]` (#16765) [ci] Use `git diff` instead of `changed-files` GH action (#16796) [syntax-errors] Improve error message and range for pre-PEP-614 decorator syntax errors (#16581) [`flake8-bandit`] Allow raw strings in `suspicious-mark-safe-usage` (`S308`) #16702 (#16770) [`refurb`] Avoid panicking `unwrap` in `verbose-decimal-constructor` (`FURB157`) (#16777) [red-knot] Add `--color` CLI option (#16758) [internal]: Upgrade salsa (#16794) Pin dependencies (#16791) [internal]: Update indirect dependencies (#16792) [ci]: Fixup codspeed upgrade (#16790) Update Rust crate compact_str to 0.9.0 (#16785) Update Rust crate clap to v4.5.32 (#16778) Update Rust crate codspeed-criterion-compat to v2.9.1 (#16784) Update Rust crate quote to v1.0.40 (#16782) Update Rust crate ordermap to v0.5.6 (#16781) Update cloudflare/wrangler-action action to v3.14.1 (#16783) Update Rust crate env_logger to v0.11.7 (#16779) ...
Summary
A small followup to #16386. We now tell the user exactly what it was about their decorator that constituted invalid syntax on Python <3.9, and the range now highlights the specific sub-expression that is invalid rather than highlighting the whole decorator
Test Plan
Inline snapshots are updated, and new ones are added.