Skip to content

[pyupgrade] Add fix safety section to docs (UP029) #17490

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Kalmaegi
Copy link
Contributor

@Kalmaegi Kalmaegi commented Apr 20, 2025

Summary

add fix safety section to UP029: unnecessary_builtin_import.rs, for #15584

I conducted some tests and found that the only side effect should be the removal of inline comments along with the code. However, during the deletion process, comments placed above the code are preserved. I'm not sure if this behavior needs to be explicitly described.

Copy link
Contributor

github-actions bot commented Apr 20, 2025

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

@VascoSch92
Copy link
Contributor

I have two example one should look into :-)

The first one is the case where we import a builtin with an alias, e.g., from builtins import str as builtin_str, is the rule removing this import or not?

For the second, let's suppose that we do something like:

# Original code
def str(x):
    return f"Custom: {x}"

# somewhere in the code
from builtins import str
result = str(1)  # Uses Python's builtin str

then the rules will correct that as

def str(x):
    return f"Custom: {x}"

result = str(1)

which is a change of behaviour.

@Kalmaegi
Copy link
Contributor Author

I have two example one should look into :-)

The first one is the case where we import a builtin with an alias, e.g., from builtins import str as builtin_str, is the rule removing this import or not?

For the second, let's suppose that we do something like:

# Original code
def str(x):
    return f"Custom: {x}"

# somewhere in the code
from builtins import str
result = str(1)  # Uses Python's builtin str

then the rules will correct that as

def str(x):
    return f"Custom: {x}"

result = str(1)

which is a change of behaviour.

The first point should be skipped, but the second one does affect the original behavior. Thank you very much!

@Kalmaegi Kalmaegi changed the title [pyupgrade] Add fix safety section to docs (UP029) [pyupgrade] Add fix safety section to docs (UP029) Apr 20, 2025
@dhruvmanila dhruvmanila added the documentation Improvements or additions to documentation label Apr 21, 2025
@dylwil3 dylwil3 self-assigned this Apr 22, 2025
dylwil3 pushed a commit that referenced this pull request Jun 23, 2025
<!--
Thank you for contributing to Ruff/ty! To help us out with reviewing,
please consider the following:

- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title? (Please prefix
with `[ty]` for ty pull
  requests.)
- Does this pull request include references to any relevant issues?
-->

## Summary

<!-- What's the purpose of the change? What does it do, and why? -->

Part of #15584

This adds a `Fix safety` section to [unnecessary-future-import
(UP010)](https://docs.astral.sh/ruff/rules/unnecessary-future-import/#unnecessary-future-import-up010)

The unsafety is determined here:

https://github.com/astral-sh/ruff/blob/d9266284df170cd70908761b5d5ae45b25523a40/crates/ruff_linter/src/rules/pyupgrade/rules/unnecessary_future_import.rs#L128-L132

Unsafe code example:
[playground](https://play.ruff.rs/c07d8c41-9ab8-4b86-805b-8cf482d450d9)
```py
from __future__ import (print_function,# ...
__annotations__)  # ...
```

Edit: It looks like there was already a PR for this, #17490, but I
missed it since they said `UP029` instead of `UP010` :/

## Test Plan

<!-- How was it tested? -->

N/A, no tests/functionality affected
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants