[refurb] Fix FURB129 autofix generating invalid syntax#18235
[refurb] Fix FURB129 autofix generating invalid syntax#18235ntBre merged 2 commits intoastral-sh:mainfrom
refurb] Fix FURB129 autofix generating invalid syntax#18235Conversation
| let unparenthesized_item_range = parenthesized_range.add_start(1.into()).sub_end(1.into()); | ||
| let item_str = checker.locator().slice(unparenthesized_item_range); | ||
| Edit::range_replacement(item_str.to_string(), expr_call.range()) |
There was a problem hiding this comment.
Is there a better way to unpack the parenthesized expression here? I looked but didn't find any.
When the expression has multiple parenthesis like in:
with open("furb129.py") as f:
for line in (((f))).readlines():
passthe fix will generate this for line in ((f)):, would that be the correct behavior or should it be just f?
There was a problem hiding this comment.
Is it necessary to remove any parentheses? Removing them when fixing for line in(f).readlines() would produce a syntax error, similar to #17683.
There was a problem hiding this comment.
Is it necessary to remove any parentheses?
Not really, I guess.
There was a problem hiding this comment.
Is it necessary to remove any parentheses? Removing them when fixing
for line in(f).readlines()would produce a syntax error, similar to #17683.
But for line in f.readlines() is not incorrect syntax. Syntax error itself is for line in(f) block: in is not a function and whitespace should not be removed
There was a problem hiding this comment.
But
for line in f.readlines()is not incorrect syntax. Syntax error itself isfor line in(f)block:inis not a function and whitespace should not be removed
for line in(f) is not a syntax error, in is lexed as a keyword and not as an identifier, so in(f) is not a function call.
|
Summary
Fixes #18231
Test Plan
Snapshot tests