-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix false positive superfluous-parens
for tuples
#4948
Fix false positive superfluous-parens
for tuples
#4948
Conversation
D = [x for x in ((3, 4) if 1 > 0 else ((5, 6)))] # [superfluous-parens] | ||
E = [x for x in ((3, 4) if 1 > 0 else ((((5, 6)))))] # [superfluous-parens] | ||
D = [x for x in ((3, 4) if 1 > 0 else ((5, 6)))] | ||
E = [x for x in ((3, 4) if 1 > 0 else ((((5, 6)))))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also add the example from the issue ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems I was to quick to push this. I hoped I could leave some checks for double parenthesis in, but seems like this only creates problems. I'm going to remove them.
Give me a minute!
Tuples can be created with inner tuples. This creates double parenthesis which we flagged incorrectly. This closes pylint-dev#4907
3e148b5
to
e60cd4b
Compare
@@ -165,11 +165,6 @@ def testCheckKeywordParensHandlesUnnecessaryParens(self): | |||
(Message("superfluous-parens", line=1, args="if"), "if (foo):", 0), | |||
(Message("superfluous-parens", line=1, args="if"), "if ((foo, bar)):", 0), | |||
(Message("superfluous-parens", line=1, args="if"), "if (foo(bar)):", 0), | |||
( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out the unittests also had a false positive.
Pull Request Test Coverage Report for Build 1189234537
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the lightning fast fix 😉
C = [x for x in ((3, 4) if 1 > 0 else (5, 6))] | ||
D = [x for x in ((3, 4) if 1 > 0 else ((5, 6)))] # [superfluous-parens] | ||
E = [x for x in ((3, 4) if 1 > 0 else ((((5, 6)))))] # [superfluous-parens] | ||
D = [x for x in ((3, 4) if 1 > 0 else ((5, 6)))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are the parens around (5, 6)
not considered superfluous here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the report in #4907
There is no good way to determine whether the parenthesises are there by accident or if they are intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies if I'm missing something obvious, but I think it should be possible if we re-implement the checker to consume the AST instead of tokens. At the AST level we would immediately know that ()
is an empty tuple and thus does require parentheses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already consume the AST so that's not really the issue here. It might be possible to fix this, but in m'n initial attempt I created a lot of false positives so we reverted to not doing this kind of check on nested tuples in comprehension.
I welcome any PR that tries to fix this though!
doc/whatsnew/<current release.rst>
.Type of Changes
Description
Tuples can be created with inner tuples. This creates double parenthesis which we flagged incorrectly.
This closes #4907