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 1 commit 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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants