Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve comma with starred expr in subscript #10997

Merged
merged 2 commits into from
Apr 17, 2024

Conversation

dhruvmanila
Copy link
Member

Summary

There have been some grammar changes in PEP 646 which were not accounted for in the old parser. The new parser has been updated with the correct AST. This is the case when there's a starred expression inside a subscript expression like the following example:

data[*x]

This gives us the AST where the slice element is actually a tuple expression with one element (starred expression) instead of just a starred expression. Now, the formatter's current behavior is to always add a trailing comma in a tuple with a single element.

This PR updates the formatter to use the "preserve" behavior in trailing comma as well. So, trailing comma will not be added in the above example and if there's a trailing comma in the above example, it'll be preserved. This retains the current behavior without the AST change.

Test Plan

Run cargo insta test -p ruff_python_formatter and make sure there are no changes.

@dhruvmanila dhruvmanila added the formatter Related to the formatter label Apr 17, 2024
Copy link

codspeed-hq bot commented Apr 17, 2024

CodSpeed Performance Report

Merging #10997 will not alter performance

Comparing dhruv/preserve-comma-with-pep-646 (4a382e5) with dhruv/parser (c30057a)

Summary

✅ 30 untouched benchmarks

Copy link
Member

@MichaReiser MichaReiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a few tests for this new syntax. Or are there pre-existing tests for this?

@dhruvmanila
Copy link
Member Author

We should add a few tests for this new syntax. Or are there pre-existing tests for this?

There are: https://github.com/astral-sh/ruff/blob/a2e71a8460b07761bd280eac3ab9dd4bd013ba92/crates/ruff_python_formatter/resources/test/fixtures/black/cases/pep_646.py although it seems there's none for trailing commas. I'll add them.

# https://peps.python.org/pep-0646/#change-2-args-as-a-typevartuple
def function_with_variadic_generics(*args: *tuple[int]): ...
def function_with_variadic_generics(
*args: *tuple[int],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intentional that you test here what happens if you have a trailing parameter comma? Should it instead test if there's a trailing tuple comma (in the subscript?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, in the presence of variadic generics, the parameter formatting shouldn't change even though this PR doesn't touch that part of the code. It's mostly to make sure of any future changes, probably not needed.

Base automatically changed from dhruv/match-seq-pattern to dhruv/parser April 17, 2024 12:47
There have been some grammar changes in [PEP 646] which were not
accounted for in the old parser. The new parser has been updated with
the correct AST. This is the case when there's a starred expression
inside a subscript expression like the following example:

```python
data[*x]
```

This gives us the AST where the slice element is actually a tuple
expression with one element (starred expression) instead of just a
starred expression. Now, the formatter's current behavior is to always
add a trailing comma in a tuple with a single element.

This PR updates the formatter to use the "preserve" behavior in trailing
comma as well. So, trailing comma will not be added in the above example
and if there's a trailing comma in the above example, it'll be
preserved. This retains the current behavior without the AST change.

[PEP 646]: https://peps.python.org/pep-0646/#change-1-star-expressions-in-indexes
@dhruvmanila dhruvmanila force-pushed the dhruv/preserve-comma-with-pep-646 branch from 4beb382 to 4a382e5 Compare April 17, 2024 12:47
@dhruvmanila dhruvmanila merged commit e9ce1d9 into dhruv/parser Apr 17, 2024
14 checks passed
@dhruvmanila dhruvmanila deleted the dhruv/preserve-comma-with-pep-646 branch April 17, 2024 12:48
Copy link
Contributor

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

dhruvmanila added a commit that referenced this pull request Apr 18, 2024
## Summary

There have been some grammar changes in [PEP 646] which were not
accounted for in the old parser. The new parser has been updated with
the correct AST. This is the case when there's a starred expression
inside a subscript expression like the following example:

```python
data[*x]
```

This gives us the AST where the slice element is actually a tuple
expression with one element (starred expression) instead of just a
starred expression. Now, the formatter's current behavior is to always
add a trailing comma in a tuple with a single element.

This PR updates the formatter to use the "preserve" behavior in trailing
comma as well. So, trailing comma will not be added in the above example
and if there's a trailing comma in the above example, it'll be
preserved. This retains the current behavior without the AST change.

[PEP 646]:
https://peps.python.org/pep-0646/#change-1-star-expressions-in-indexes

## Test Plan

Run `cargo insta test -p ruff_python_formatter` and make sure there are
no changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatter Related to the formatter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants