-
-
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
New check simplifiable-condition
and add bool() check for len-as-condition
#3644
New check simplifiable-condition
and add bool() check for len-as-condition
#3644
Conversation
f50bc26
to
413dbf8
Compare
Hey @ethan-leba Thanks for the PR. Can you split this into three separate PRs? As it stands now, it includes three changes that are easier to review separately. |
961974b
to
748657d
Compare
Definitely agree this PR is a little overloaded, but the reason it ended up like that is because the main commit containing the checker depends on refactoring changes made in the first. I removed the last commit, and will PR it separately if/when the other changes get in, but I think the first two commits are too coupled to split into separate PRs. |
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.
Hey @ethan-leba Looking great, thanks for the work. Left several comments we should check out before we can pull it in.
assert False and False # [simplifiable-condition] | ||
|
||
# Expressions not in one of the above situations will not emit a message | ||
CONSTANT or True |
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.
Let's add a test for something that is not uninferable:
CONSTANT or True | |
from unknown import Unknown | |
bool(Unknown or True) # should not emit |
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.
Shouldn't bool(Unknown or True)
emit an error, as it can be simplified to True
?
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.
Not quite, as we do not know what Unknown
actually is at runtime.
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.
But in this case the value of Unknown shouldn't matter:
>>> Unknown = False
>>> bool(Unknown or True)
True
>>> Unknown = True
>>> bool(Unknown or True)
True
>>> Unknown = 123
>>> bool(Unknown or True)
True
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.
The reason why CONSTANT or True
in the test-case above doesn't emit an error is b/c it's not in a condition, so the value of CONSTANT
affects the result, for example:
>>> CONSTANT = 0
>>> CONSTANT or True
True
>>> CONSTANT = -134
>>> CONSTANT or True
-134
Just wanted to point that out in case that was the source of confusion!
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.
Can I move forward with splitting the checker, or should I wait for PCManticore's input on this? I don't think it should be too difficult.
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.
Yeah I think you can go on and do it. Looking at @PCManticore profile he seems to be quite busy with "not gihub thing" lately and he's probably spammed with other github issues anyway. With two positives review + this comment I'm confident enough to merge myself.
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.
Okay, sounds good! Just one question about suspicious-boolean-condition
, should this checker target single constants in conditionals, i.e. if True:
or bool(True)
? Currently this checker would only emit a message if the expression can be reduced to a single constant, but not if the expression is a single constant.
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.
Hmm, yes probably. If it's really hard to disentangle the code, we can probably create an issue to do it separately.
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.
using-constant-test
should cover the case of single constants mentioned above
simplifiable-condition
, add bool() check for len-as-condition
, and contextual messages for singleton-comparison
simplifiable-condition
and add bool() check for len-as-condition
748657d
to
93f9491
Compare
Thanks for the review @PCManticore! Revised the PR, just left one question above |
f322004
to
a42dd91
Compare
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.
Very nice feature!
Anything else that needs to be done on my part to move this PR forward @PCManticore ? |
It seems like there is an ongoing discussion about the message of the recommendation that could be made better, but I'll let @PCManticore confirm if I understood correctly when he's available. In the meantime could you rebase on the latest master, please? |
a42dd91
to
b083152
Compare
8eac6d4
to
4c28ea0
Compare
4c28ea0
to
7dd2ae5
Compare
I've split off simplification to a constant to a separate check: |
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.
This look clean and well tested, thank you ! But I wonder what is the difference between simplifiable condition and condition eval to constant. Because the two functional test files look the same (with False and True inverted) and gives a very different result. Why is bool(CONSTANT or False) # [simplifiable-condition]
and bool(CONSTANT or True) # [condition-evals-to-constant]
? What is the difference between the two ?
|
Sorry, it makes sense (again) now. Thank you for explaining it another time and thank you for this very nice addition to Pylint. Simplifying boolean conditions is always very satisfying and useful. |
Steps
doc/whatsnew/<current release.rst>
.Description
bool(len(x))
tolen-as-condition
.simplifiable-condition
check to the refactoring checker, which will suggest removing constants that have no effect on a boolean condition, i.e.False or x
->x
, and replacing conditions with a constant if there is a shortcircuiting value, i.e.True or x
->True
.Type of Changes
Related Issue
Closes #3407