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

typevars becoming types with typevars doesn't work #1236

Closed
ddfisher opened this issue Feb 24, 2016 · 5 comments
Closed

typevars becoming types with typevars doesn't work #1236

ddfisher opened this issue Feb 24, 2016 · 5 comments
Labels
bug mypy got something wrong

Comments

@ddfisher
Copy link
Collaborator

from typing import TypeVar
T = TypeVar('T')
V = TypeVar('V')

def identity(x: T) -> T: ...
def type_var_using_fn(x: V) -> None: ...
identity(type_var_using_fn)

has the confusing error:

test.py:10: error: Argument 1 to "identity" has incompatible type Callable[[V], None]; expected Callable[[V], None]

This is most commonly seen when decorating functions with TypeVars.

@JukkaL JukkaL added the bug mypy got something wrong label Feb 24, 2016
@JukkaL
Copy link
Collaborator

JukkaL commented Feb 24, 2016

This could be another manifestation of the old type variable renaming bug (#230 or #603 may be related.)

@gnprice gnprice modified the milestone: 0.3.3 Mar 1, 2016
@rwbarton
Copy link
Contributor

rwbarton commented Apr 5, 2016

Here's what's happening here:

  • We need to typecheck the expression identity(type_var_using_fn).
  • Since identity is a generic function, we have to infer the correct T to pick for the call based on the argument. mypy correctly determines that T = def [V] (x: V-1), the type of the generic function type_var_using_fn`.
  • Having chosen T, we need to check that the arguments are actually valid. In this case, this means checking that the actual argument type def [V] (x: V-1)is a subtype of the formal argument typeT = def [V] (x: V-1). Of course it is, but checking whether a callable is a subtype of a generic callable is not yet supported by mypy, resulting in the confusing error message.

I think the mypythonic thing to do here is to just implement this subtyping check: A callable is a subtype of a generic callable if it is so after the generic callable is instantiated at fresh ("skolem") types.

@ddfisher
Copy link
Collaborator Author

ddfisher commented Apr 5, 2016

Thanks for tracking this down! I agree, implementing that subtyping check sounds like the right fix here.

@gvanrossum
Copy link
Member

gvanrossum commented Apr 5, 2016 via email

@rwbarton
Copy link
Contributor

rwbarton commented Apr 6, 2016

I have what should be a fix, but encountered #1335 while testing it.

rwbarton added a commit to rwbarton/mypy that referenced this issue Apr 6, 2016
This ended up just amounting to removing a check!

Fixes python#1236.
rwbarton added a commit to rwbarton/mypy that referenced this issue Apr 6, 2016
This ended up amounting to just removing a check!

Fixes python#1236.
rwbarton added a commit to rwbarton/mypy that referenced this issue Apr 6, 2016
This ended up amounting to just removing a check!

Fixes python#1236. But something is still not right when using type
variables constrained to a list of values; added a failing test for
that case.
rwbarton added a commit to rwbarton/mypy that referenced this issue Apr 6, 2016
This ended up amounting to just removing a check!

Fixes python#1236. But something is still not right when using type
variables constrained to a list of values; added a failing test for
that case.
gvanrossum pushed a commit that referenced this issue Apr 6, 2016
This ended up amounting to just removing a check!



Fixes #1236. But something is still not right when using type

variables constrained to a list of values; added a failing test for

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

No branches or pull requests

5 participants