Skip to content

Strange error for overloaded get() method and Tuple key value #1595

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
gvanrossum opened this issue May 30, 2016 · 1 comment
Closed

Strange error for overloaded get() method and Tuple key value #1595

gvanrossum opened this issue May 30, 2016 · 1 comment
Assignees

Comments

@gvanrossum
Copy link
Member

gvanrossum commented May 30, 2016

This came up when I merged python/typeshed#223.
I think I have a complete repo that doesn't depend on the stubs. Consider this:

from typing import TypeVar, Generic, Tuple, overload

KT = TypeVar('KT')
VT = TypeVar('VT')

class A(Generic[KT, VT]):
    def get(self, arg: KT) -> VT:
        pass

a = A()  # type: A[Tuple[int, int], int]
a.get((0, 0))  # OK

class B(Generic[KT, VT]):
    @overload
    def get(self, arg: KT) -> VT:
        pass
    @overload
    def get(self, arg: KT, default: VT) -> VT:
        pass

b1 = B()  # type: B[int, int]
b1.get(0)  # OK
b2 = B()  # type: B[Tuple[int, int], int]
b2.get((0, 0))  # error here

I get an error on the very last line (b2.get((0, 0)):

x.py:24: error: No overload variant of "get" of "B" matches argument types [Tuple[builtins.int, builtins.int]]

But there's no error two lines above, on b1.get(0). Also note that the same code with class A which does not overload get()) has no errors. I've got a feeling that there's a subtle bug in the handling of type variables that only shows up when a Tuple is matched against an overloaded method.

@rwbarton Any thoughts? Or @JukkaL ?

@JukkaL
Copy link
Collaborator

JukkaL commented May 30, 2016

I looked at this and noticed that the fallback of tuple types are inconsistent. One of the tuple types it is builtins.tuple[builtins.int], and the other it's just builtins.tuple. We should always have the first form. In addition, erasing tuple types was broken, as the fallback didn't get erased.

@JukkaL JukkaL self-assigned this May 30, 2016
JukkaL added a commit that referenced this issue May 30, 2016
Fixes #1595.

There were actually two issues:

* Erasing tuple types was incorrect, as the fallback type was not erased.
* Some tuple types got generated without a type argument, even though
  a uniform tuple type is internally represented as instance type tuple[t].

Similar issues might still arise in other contexts but at least this is
improves things a little.

Also, we generate fallback types that are like Tuple[Any, ...]. We could
potentially generate a more precise fallback type, but that would potentially
require joins and I'm not sure if we can use them during semantic analysis.
JukkaL added a commit that referenced this issue May 30, 2016
Fixes #1595.

There were actually two issues:

* Erasing tuple types was incorrect, as the fallback type was not erased.
* Some tuple types got generated without a type argument, even though
  a uniform tuple type is internally represented as instance type tuple[t].

Similar issues might still arise in other contexts but at least this is
improves things a little.

Also, we generate fallback types that are like Tuple[Any, ...]. We could
potentially generate a more precise fallback type, but that would potentially
require joins and I'm not sure if we can use them during semantic analysis.
gvanrossum pushed a commit that referenced this issue May 30, 2016
Fixes #1595.

There were actually two issues:

* Erasing tuple types was incorrect, as the fallback type was not erased.
* Some tuple types got generated without a type argument, even though
  a uniform tuple type is internally represented as instance type tuple[t].

Similar issues might still arise in other contexts but at least this is
improves things a little.

Also, we generate fallback types that are like Tuple[Any, ...]. We could
potentially generate a more precise fallback type, but that would potentially
require joins and I'm not sure if we can use them during semantic analysis.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants