-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Avoid FURB113
autofix if comments are present
#8494
Conversation
|
I'm a little torn on this because there's now no way to access this fix whereas with |
@zanieb - Do you have an opinion on this issue more broadly (of fixes that delete comments)? I could see us marking them as unsafe, or as display, or omitting them entirely as in this PR. |
(I am the author of the original issue.) If possible, I would prefer to just put the autofix below the comments, as it is otherwise a good fix as you said. Another option could be to write the autofix over multiple lines keeping the comments in place, but I suspect that would be much more difficult to implement: -nums.append(4)
+nums.extend((4,
# Critically important comment 1
-nums.append(5)
+5,
# Critically important comment 2
-nums.append(6)
+6)) |
This seems to already be an unsafe fix. I'd actually then go with display only for this one.
Yeah, we'd probably need to use LibCST to construct the fix instead. |
2de566c
to
12db68b
Compare
I'm going forward with the current solution as it's consistent with various other rules ( |
I feel like all of those should just be unsafe. I don't think we should prevent the user from accessing the fix due to comments -- they should just have to opt in. But I'd like @zanieb's opinion too. (Not asking for any changes right now.) |
This PR avoids creating the fix for
FURB113
if there are comments in between theappend
calls.fixes: #8105