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

Use non-parenthesized range for DebugText #9953

Merged
merged 1 commit into from
Feb 12, 2024
Merged

Conversation

dhruvmanila
Copy link
Member

@dhruvmanila dhruvmanila commented Feb 12, 2024

Summary

This PR fixes the DebugText implementation to use the expression range instead of the parenthesized range.

Taking the following code snippet as an example:

x = 1
print(f"{  ( x  ) = }")

The output of running it would be:

  ( x  ) = 1

Notice that the whitespace between the parentheses and the expression is preserved as is.

Currently, we don't preserve this information in the AST which defeats the purpose of DebugText as the main purpose of the struct is to preserve whitespaces around the expression.

This is also problematic when generating the code from the AST node as then the generator has no information about the parentheses the whitespaces between them and the expression which would lead to the removal of the parentheses in the generated code.

I noticed this while working on the f-string formatting where the debug text would be used to preserve the text surrounding the expression in the presence of debug expression. The parentheses were being dropped then which made me realize that the problem is instead in the parser.

Test Plan

  1. Add a test case for the parser
  2. Add a test case for the generator

@dhruvmanila dhruvmanila added bug Something isn't working parser Related to the parser labels Feb 12, 2024
@MichaReiser
Copy link
Member

Can you add a short explanation why it should use the expression range instead of the parenthesized range?

Copy link
Contributor

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

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.

Thanks for the explanation. It helped me understand the change and makes this a very easy review :)

@dhruvmanila dhruvmanila changed the title Update DebugText with non-parenthesized range Use non-parenthesized range for DebugText Feb 12, 2024
@dhruvmanila dhruvmanila merged commit 33ac286 into main Feb 12, 2024
17 checks passed
@dhruvmanila dhruvmanila deleted the dhruv/fix-debug-text branch February 12, 2024 17:30
nkxxll pushed a commit to nkxxll/ruff that referenced this pull request Mar 10, 2024
## Summary

This PR fixes the `DebugText` implementation to use the expression range
instead of the parenthesized range.

Taking the following code snippet as an example:
```python
x = 1
print(f"{  ( x  ) = }")
```

The output of running it would be:
```
  ( x  ) = 1
```

Notice that the whitespace between the parentheses and the expression is
preserved as is.

Currently, we don't preserve this information in the AST which defeats
the purpose of `DebugText` as the main purpose of the struct is to
preserve whitespaces _around_ the expression.

This is also problematic when generating the code from the AST node as
then the generator has no information about the parentheses the
whitespaces between them and the expression which would lead to the
removal of the parentheses in the generated code.

I noticed this while working on the f-string formatting where the debug
text would be used to preserve the text surrounding the expression in
the presence of debug expression. The parentheses were being dropped
then which made me realize that the problem is instead in the parser.

## Test Plan

1. Add a test case for the parser
2. Add a test case for the generator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working parser Related to the parser
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants