Skip to content
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

Type changes in decorators are not detected #2578

Open
olirice opened this issue Nov 1, 2018 · 6 comments
Open

Type changes in decorators are not detected #2578

olirice opened this issue Nov 1, 2018 · 6 comments
Labels
Decorators False Negative 🦋 No message is emitted but something is wrong with the code inference Needs PR This issue is accepted, sufficiently specified and now needs an implementation

Comments

@olirice
Copy link

olirice commented Nov 1, 2018

When a decorator changes the return type of a function, that change is not detected.

Steps to reproduce

from typing import Callable
from functools import wraps

def cast_to_str(func) -> Callable[..., str]:
    @wraps(func)
    def wrapper(*args, **kwargs):
        return str(func(*args, **kwargs))
    return wrapper

@cast_to_str
def get_num() -> int:
    return 5

get_num().strip()
# [no-member] Instance of 'int' has no 'strip' member 

Current behavior

Return type of decorated function is set by the function declaration

Expected behavior

Return type of the function set by decorator

pylint --version output

pylint 2.1.1
astroid 2.0.4
Python 3.6.5 (default, May 14 2018, 11:01:09)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)]

@PCManticore
Copy link
Contributor

Thanks for creating an issue! pylint doesn't currently correctly understand decorators, which is why it does not infer the new type.

@moi90
Copy link

moi90 commented Oct 21, 2019

Is there any roadmap towards this?

@PCManticore
Copy link
Contributor

No, there isn't. pylint is a volunteer driven project and the roadmap tends to be the things that volunteers are mostly interested in working on. For now this is not a priority but hopefully we'll get to it at some point.

@moi90
Copy link

moi90 commented Oct 21, 2019

I understand. Is there already any discussion about this or is this issue the right place to start one?

@PCManticore
Copy link
Contributor

This is the right place to start one. :)

@Pierre-Sassoulas
Copy link
Member

A lot of similar issues were listed in #8332

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Decorators False Negative 🦋 No message is emitted but something is wrong with the code inference Needs PR This issue is accepted, sufficiently specified and now needs an implementation
Projects
None yet
Development

No branches or pull requests

4 participants