-
-
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
inconsistent-return-statements with raise in function call #1782
Comments
Same issue even with no function call: def do_foo(a_arg):
if a_arg:
return "foo"
assert False
|
- 1.8.1 gives weird inconsistent return errors - pylint-dev/pylint#1782
* Update docs/submodules/yardstick from branch 'master' - Remove 'inconsistent-return-statements' check from Pylint There are several bugs in Pylint [1] [2] affecting 'inconsistent-return-statements' check. It will be temporarily removed. [1] pylint-dev/pylint#1782 [2] pylint-dev/pylint#1794 JIRA: YARDSTICK-911 Change-Id: Ib655ef1befdc734c646cdfb9b48f1db0ccdf676d Signed-off-by: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@intel.com>
There are several bugs in Pylint [1] [2] affecting 'inconsistent-return-statements' check. It will be temporarily removed. [1] pylint-dev/pylint#1782 [2] pylint-dev/pylint#1794 JIRA: YARDSTICK-911 Change-Id: Ib655ef1befdc734c646cdfb9b48f1db0ccdf676d Signed-off-by: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@intel.com>
@PCManticore, for the first issue it seems that we have to ensure that the function called will always end with a |
But on the other hand, this causes a bogus inconsistent-return-statement:
But if return_error returns ValueError, then it does not cause inconsistent-return-statement, so that appears to just be a special case of #1794, second function. |
This function also causes an def func(done):
while True:
if done():
return 42 So perhaps the problem is not in how |
@ddaanet thank you for your remarks! |
@hippo91 I agree with you and with @ddaanet as well. The expectations for this check should be that it cannot detect all the edge cases, but should work most of the time. If it needs flow control understanding to determine if the end of a function is reachable or not, then the simplest solution would be to disable the message locally and move on. |
This is hopefully caused by pylint-dev/pylint#1782 so will be fixed sometime after pylint 1.8.3.
@hippo91 Indeed, @mthuurne's #1782 (comment) does not reproduce on 2.0 anymore. But this does: def func():
if True:
while True:
break
return True
else:
raise RuntimeError() (Sure, doesn't make much sense as is.) |
@tuukkamustonen thanks for your remark. I'll work on your issue ASAP. |
@tuukkamustonen in your example pylint warns you that the else statement is useless. For example: #pylint: disable=C0111
def func(val):
if val <= 3:
while True:
break
return True
raise RuntimeError() doesn't raise any messages. |
@hippo91 True, if you remove But the warning still shouldn't be there with Besides, behind that unnecessary |
It's possible in pylint to disable individual messages, so a user might have the message about unnecessary |
I'm not exactly sure how is that message a false positive for the following:
This is exactly what this check is supposed to catch, so not sure where the stylistic reason comes into. Or is the complaint that the message should be improved? @mthuurne Yes, it's possible in pylint to disable individual messages, both in the configuration file and at the CLI. |
What I meant is that since individual messages can be disabled, every message should be considered in isolation. The motivation given for closing the I think that the false positive that @tuukkamustonen referred to is the |
Ah gotcha, the false positive was |
Yes, this. (I wasn't even aware there's |
@tuukkamustonen @mthuurne you are effectively right. |
Correcting the way if statements are determined as return ended or not. Close #1782
@PCManticore, @hippo91
I guess the issue still persists! I am having the following code
Current Behaviour
Expected Behaviour Thanks! |
I think PyLint is correct here: the Note that this issue was originally about |
@mthuurne |
"""importing datetime module""" def days_in_month(year, month):
def is_valid_date(year, month, day):
x = int(input()) l = int(input()) Iam getting either all the return statements should return an expression or none of them should in days_in_month function. |
@nikitha9792000
|
@hippo91 |
functions that always raise are useful, be nice if you could just use type hints to point it out. |
Agreed: a Given how confusing the history of this issue already is, it might be better to open a new issue for that feature request instead of continuing here. |
@earonesty @mthuurne you are right but no need to open a new issue as it would be a duplicate of #4122. There is already a PR for this #4304. |
Hello!
Steps to reproduce
Current behavior
Does not recognize
raise
in the function call.In this case depth is only 1, but can be more.
Expected behavior
I think it should.
pylint --version output
Thanks!
The text was updated successfully, but these errors were encountered: