Skip to content

Incorrect use of Any in second occurrence of type in signature #6089

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

Closed
wilcoxjay opened this issue Dec 19, 2018 · 2 comments
Closed

Incorrect use of Any in second occurrence of type in signature #6089

wilcoxjay opened this issue Dec 19, 2018 · 2 comments
Labels
bug mypy got something wrong priority-1-normal

Comments

@wilcoxjay
Copy link

wilcoxjay commented Dec 19, 2018

Consider the following code.

from __future__ import annotations
from typing import Optional

class C1(object):
    def foo(self, a: C, b: C) -> None:
        reveal_type(a)  # Optional[C1]
        reveal_type(b)  # Any

    def bar(self, a: C) -> C:
        reveal_type(a)  # Optional[C1]
        return a

    def baz(self) -> C:
        return C()

C = Optional[C1]
        
def main() -> None:
    reveal_type(C1().foo)  # def (a: Optional[C1], b: Any)
    reveal_type(C1().bar)  # def (a: Optional[C1]) -> Any
    reveal_type(C1().baz)  # def () -> Optional[C1]

Note that C is defined after the class body of C1, but C is used in several type annotations in the body of C1 (taking advantage of from __future__ import annotations).

In each method of C1, the first occurrence of C is correctly used by mypy, but subsequent occurrences (in later parameter types or the return type) are incorrectly interpreted as Any.

If I move the alias definition C = Optional[C1] above the class body (and fix the resulting forward reference using a string), then everything works.

If this is the expected behavior, then consider this issue a request for a better error message than silently inferring Any.

I observe this behavior both on mypy version 0.650 and on the most recent master (01c268644).

@ilevkivskyi
Copy link
Member

Thanks for reporting! This is definitely a bug.

Note there is a similar issue #5842. Maybe this problem is somehow related to deferred nodes?

@ilevkivskyi ilevkivskyi added bug mypy got something wrong priority-1-normal labels Dec 19, 2018
@ilevkivskyi
Copy link
Member

This now works correctly, I get:

tstdefer.py:6: note: Revealed type is "Union[tstdefer.C1, None]"
tstdefer.py:7: note: Revealed type is "Union[tstdefer.C1, None]"
tstdefer.py:10: note: Revealed type is "Union[tstdefer.C1, None]"
tstdefer.py:14: error: "<typing special form>" not callable  [operator]
tstdefer.py:19: note: Revealed type is "def (a: Union[tstdefer.C1, None], b: Union[tstdefer.C1, None])"
tstdefer.py:20: note: Revealed type is "def (a: Union[tstdefer.C1, None]) -> Union[tstdefer.C1, None]"
tstdefer.py:21: note: Revealed type is "def () -> Union[tstdefer.C1, None]"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong priority-1-normal
Projects
None yet
Development

No branches or pull requests

2 participants