-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Decorator on __init__ causes loss of type info #5398
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
Decorator on __init__ causes loss of type info #5398
Comments
Try again after adding |
Adding annotations to
I get the same result (the revealed type is |
|
I just stumbled at this again. Even precisely typed decorator on from typing import Any, Callable, TypeVar
_C = TypeVar("_C", bound=Callable[..., None])
def decorator(f: _C) -> _C:
return f
class C:
@decorator
def __init__(self, x: int) -> None:
...
C("whatever", "works", "now") + 42 |
Increased priority to "high" since this behavior is very unexpected and can hide bugs. |
It looks like #1706 is a special case of this. FYI, I am working on a PR to fix this. It seems like the problem is that quite a few places check whether a node represents a callable function by checking if it is an instance of |
This allows mypy to understand the type signatures of functions decorated with @typeguard.typechecked, allowing the type signatures on such functions to be used by both enforce and mypy. Prior to this commit, adding @TypeChecked removed the ability of mypy to type-check calls to decorated functions, as it did not understand that the type of such a decorated function is the same as the original function. The added stub makes this declaration. The test-suite mypy calls are modified to use that stub file. The immediate motivation for this is to keep mypy passing when adding a type annotation for parsl.load; that type annotation is also added in this commit. This commit fixes some of problem described in the commit message for d7d9a25 about breaking mypy type checking for end user Configs in some places, but by no means all of it. However there is a mypy bug, python/mypy#5398, where decorated __init__ methods are not properly type-checked by mypy, which means that mypy typechecking is still missing on any decorated __init__ methods - which unfortunately is most of the user-facing type checked code. At time of writing, there are PRs open to fix this in mypy, so there is hope; and that does not impede this PR being merged.
This allows mypy to understand the type signatures of functions decorated with @typeguard.typechecked, allowing the type signatures on such functions to be used by both enforce and mypy. Prior to this commit, adding @TypeChecked removed the ability of mypy to type-check calls to decorated functions, as it did not understand that the type of such a decorated function is the same as the original function. The added stub makes this declaration. The test-suite mypy calls are modified to use that stub file. The immediate motivation for this is to keep mypy passing when adding a type annotation for parsl.load; that type annotation is also added in this commit. This commit fixes some of problem described in the commit message for d7d9a25 about breaking mypy type checking for end user Configs in some places, but by no means all of it. However there is a mypy bug, python/mypy#5398, where decorated __init__ methods are not properly type-checked by mypy, which means that mypy typechecking is still missing on any decorated __init__ methods - which unfortunately is most of the user-facing type checked code. At time of writing, there are PRs open to fix this in mypy, so there is hope; and that does not impede this PR being merged.
Here's a simple example:
The output of mypy is:
This seems to be specific to methods as similar type inferences work fine for functions outside of the class scope.
The text was updated successfully, but these errors were encountered: