Detect assignment expressions before Python 3.8 #16383
Draft
+222
−30
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
ntBre
added a commit
that referenced
this pull request
Feb 26, 2025
Summary -- This PR detects another syntax error from #6591 and is stacked on #16383. This time the relaxed grammar for decorators proposed in [PEP 614](https://peps.python.org/pep-0614/) is detected for Python 3.8 and lower. The 3.8 grammar for decorators is [here](https://docs.python.org/3.8/reference/compound_stmts.html#grammar-token-decorators): ``` decorators ::= decorator+ decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE dotted_name ::= identifier ("." identifier)* ``` in contrast to the current grammar [here](https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-decorators) ``` decorators ::= decorator+ decorator ::= "@" assignment_expression NEWLINE assignment_expression ::= [identifier ":="] expression ``` This was the trickiest one of these to detect yet. It seemed like the best approach was to attempt to parse the old version and fall back on the new grammar if anything goes wrong, but I'm not as confident in this approach since it required adding a `Parser::try_parse_old_decorators` method. Test Plan -- New inline parser tests and linter CLI tests.
ntBre
added a commit
that referenced
this pull request
Feb 26, 2025
Summary -- This PR detects another syntax error from #6591 and is stacked on #16383. This time the relaxed grammar for decorators proposed in [PEP 614](https://peps.python.org/pep-0614/) is detected for Python 3.8 and lower. The 3.8 grammar for decorators is [here](https://docs.python.org/3.8/reference/compound_stmts.html#grammar-token-decorators): ``` decorators ::= decorator+ decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE dotted_name ::= identifier ("." identifier)* ``` in contrast to the current grammar [here](https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-decorators) ``` decorators ::= decorator+ decorator ::= "@" assignment_expression NEWLINE assignment_expression ::= [identifier ":="] expression ``` This was the trickiest one of these to detect yet. It seemed like the best approach was to attempt to parse the old version and fall back on the new grammar if anything goes wrong, but I'm not as confident in this approach since it required adding a `Parser::try_parse_old_decorators` method. Test Plan -- New inline parser tests and linter CLI tests.
ntBre
force-pushed
the
brent/syntax-walrus-38
branch
from
d8231f5 to
f73d2b2
Compare
ntBre
added a commit
that referenced
this pull request
Feb 26, 2025
Summary -- This PR detects another syntax error from #6591 and is stacked on #16383. This time the relaxed grammar for decorators proposed in [PEP 614](https://peps.python.org/pep-0614/) is detected for Python 3.8 and lower. The 3.8 grammar for decorators is [here](https://docs.python.org/3.8/reference/compound_stmts.html#grammar-token-decorators): ``` decorators ::= decorator+ decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE dotted_name ::= identifier ("." identifier)* ``` in contrast to the current grammar [here](https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-decorators) ``` decorators ::= decorator+ decorator ::= "@" assignment_expression NEWLINE assignment_expression ::= [identifier ":="] expression ``` This was the trickiest one of these to detect yet. It seemed like the best approach was to attempt to parse the old version and fall back on the new grammar if anything goes wrong, but I'm not as confident in this approach since it required adding a `Parser::try_parse_old_decorators` method. Test Plan -- New inline parser tests and linter CLI tests.
ntBre
force-pushed
the
brent/syntax-walrus-38
branch
from
fdd6918 to
6cda055
Compare
ntBre
added a commit
that referenced
this pull request
Feb 26, 2025
Summary -- This PR detects another syntax error from #6591 and is stacked on #16383. This time the relaxed grammar for decorators proposed in [PEP 614](https://peps.python.org/pep-0614/) is detected for Python 3.8 and lower. The 3.8 grammar for decorators is [here](https://docs.python.org/3.8/reference/compound_stmts.html#grammar-token-decorators): ``` decorators ::= decorator+ decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE dotted_name ::= identifier ("." identifier)* ``` in contrast to the current grammar [here](https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-decorators) ``` decorators ::= decorator+ decorator ::= "@" assignment_expression NEWLINE assignment_expression ::= [identifier ":="] expression ``` This was the trickiest one of these to detect yet. It seemed like the best approach was to attempt to parse the old version and fall back on the new grammar if anything goes wrong, but I'm not as confident in this approach since it required adding a `Parser::try_parse_old_decorators` method. Test Plan -- New inline parser tests and linter CLI tests.
ntBre
added a commit
that referenced
this pull request
Feb 26, 2025
Summary -- This PR detects another syntax error from #6591 and is stacked on #16383. This time the relaxed grammar for decorators proposed in [PEP 614](https://peps.python.org/pep-0614/) is detected for Python 3.8 and lower. The 3.8 grammar for decorators is [here](https://docs.python.org/3.8/reference/compound_stmts.html#grammar-token-decorators): ``` decorators ::= decorator+ decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE dotted_name ::= identifier ("." identifier)* ``` in contrast to the current grammar [here](https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-decorators) ``` decorators ::= decorator+ decorator ::= "@" assignment_expression NEWLINE assignment_expression ::= [identifier ":="] expression ``` This was the trickiest one of these to detect yet. It seemed like the best approach was to attempt to parse the old version and fall back on the new grammar if anything goes wrong, but I'm not as confident in this approach since it required adding a `Parser::try_parse_old_decorators` method. Test Plan -- New inline parser tests and linter CLI tests.
This PR is the first in a series derived from #16308, each of which add support for detecting one version-related syntax error from #6591. This one should be the largest because it also includes a couple of additional changes: 1. the `syntax_errors!` macro, which makes adding more variants a bit easier 2. the `Parser::add_unsupported_syntax_error` method Otherwise I think the general structure will be the same for each syntax error: * Detecting the error in the parser * Inline parser tests for the new error * New ruff CLI tests for the new error Because of the second point here, this PR is currently stacked on #16357. As noted above, there are new inline parser tests, as well as new ruff CLI tests. Once #16379 is resolved, there should also be new mdtests for red-knot, but this PR does not currently include those.
ntBre
force-pushed
the
brent/syntax-walrus-38
branch
from
6cda055 to
3c98d84
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR is the first in a series derived from #16308, each of which add support
for detecting one version-related syntax error from #6591. This one should be
the largest because it also includes a couple of additional changes:
syntax_errors!macro, which makes adding more variants a bit easierParser::add_unsupported_syntax_errormethodOtherwise I think the general structure will be the same for each syntax error:
Because of the second point here, this PR is currently stacked on #16357.
Test Plan
As noted above, there are new inline parser tests, as well as new ruff CLI
tests. Once #16379 is resolved, there should also be new mdtests for red-knot,
but this PR does not currently include those.