Pylint does not discover a NoReturn method in certain cases to avoid "inconsistent-return-statements"
e-gebes opened this issue · 3 comments
Bug description
from typing import NoReturn
def raise_function() -> NoReturn:
raise RuntimeError
class MyClass:
@staticmethod
def raise_staticmethod() -> NoReturn:
raise RuntimeError
@classmethod
def raise_classmethod(cls) -> NoReturn:
raise RuntimeError
def raise_instance_method(self) -> NoReturn:
raise RuntimeError
def test_case_1(): # function -> OK
if __name__:
return None
raise_function()
def test_case_2(): # staticmethod -> OK
if __name__:
return None
MyClass.raise_staticmethod()
def test_case_3a(): # classmethod called on class -> OK
if __name__:
return None
MyClass.raise_classmethod()
def test_case_3b(): # classmethod called on instance -> OK
if __name__:
return None
MyClass().raise_classmethod()
def test_case_4a(obj): # instance method called on anonymous obj -> fails
if __name__:
return None
obj.raise_instance_method()
def test_case_4b(obj: MyClass): # instance method called on type hinted obj -> fails
if __name__:
return None
obj.raise_instance_method()
def test_case_4c(): # instance method called on ad-hoc created instance -> OK
if __name__:
return None
MyClass().raise_instance_method()
def test_case_4d(obj): # instance method called on class (avoiding the "self magic") -> fails
if __name__:
return None
MyClass.raise_instance_method(obj)
Configuration
No response
Command used
pylint a.py
Pylint output
************* Module a
45:0: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)
51:0: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)
63:0: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)
Expected behavior
This is a follow-up from: #1782 #4122 #4304
About the failing test cases 4a, 4b, 4d:
4a: seems hard to improve something about it - maybe Pylint could check all usages in the current project, and if all lead consistently to "NoReturn", suppress the warning. In my view checking occurrences alone might not be sensible to do, but wanted to mention the idea.
4b: would be nice if this worked, but is out of scope here, is related to type hint issues #9674 and #4813
4d: if Pylint gets case 4c right, I think it should also work with 4d. If this would be fixed, it would be an alternative to be used to avoid the inconsistent-return-statements
warning before making use of type hints (4b) or more elaborate introspection (4a?) are available, which might not be soon.
Please think about improving Pylint to work also with case 4d.
Pylint version
pylint 2.17.7
astroid 2.15.8
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0]
OS / Environment
No response
Additional dependencies
No response
Thank you for opening the issue, it look like a duplicate of #9674
Thank you for opening the issue, it look like a duplicate of #9674
Thank you for the reply and link! I had a look and read into the discussion, also into #4813. I understand there is a general need to do underlying work to make Pylint better use type hints, and as well there is the general question: use more type hints like a type checker, or keep improving inference, or maybe a combination?
My issue report is related to type hints, in that sense it is a duplicate of the linked issues.
Anyway, I tried more things what works and what not. See my edited original report comment!
The type hints example (4b) I labelled as out of scope, I rephrased the title to make it independent of type hints. Meanwhile added case 4d might be relevant, please have a look again and consider re-opening the issue.
We can track this separately. The RefactoringChecker needs to call utils.is_terminating_func()
somewhere.