-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Comments
I looked at this and noticed that the |
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
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:
I get an error on the very last line (
b2.get((0, 0)
):But there's no error two lines above, on
b1.get(0)
. Also note that the same code with class A which does not overloadget()
) 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 ?
The text was updated successfully, but these errors were encountered: