Skip to content

meet.py should consider all Tuple[t1, t2, ...] as subtypes of plain tuple #2465

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

Merged
merged 3 commits into from
Nov 22, 2016

Conversation

ilevkivskyi
Copy link
Member

Fixes #1691
Fixes #2456

This is a simple-minded fix. In the future we could add more rules for tuples in meet.py (for example for homogeneous tuples, a tuple and an iterable etc).

Tests are based on (extended) examples discussed in issues.

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 16, 2016

Thanks for the fix!

I'm going to postpone merging this until after 0.4.6 as we are very close to the release.

@ilevkivskyi
Copy link
Member Author

@JukkaL Just pinging this. (I am working on other thing that would be easier with this fix merged.)

@@ -243,6 +245,10 @@ def visit_tuple_type(self, t: TupleType) -> Type:
items.append(self.meet(t.items[i], self.s.items[i]))
# TODO: What if the fallbacks are different?
return TupleType(items, t.fallback)
# Special case: all Tuple[t1, t2, ...] are subtypes of plain tuple.
elif (isinstance(self.s, Instance) and self.s.type.fullname() == 'builtins.tuple'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also handle cases like the meet of Tuple[int, int] and Tuple[int, ...]. However, as this is slightly trickier, it's okay to add a comment here about this and create a follow-up issue. Which would you prefer?

Implementing the general case shouldn't be hard, though it's not urgent really. The meet of arbitrary Tuple[t1, <...>, tn] and Tuple[s, ...] (where <...> would not be a Python ellipsis but a mathematical one) would be Tuple[meet(t1, s), ..., meet(tn, s)], I think. So the meet of types Tuple[X, Y] and Tuple[Z, ...] would be Tuple[meet(X, Z), meet(Y, Z)], etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JukkaL OK, I made this apply for all homogeneous tuples (instead of special-casing bare tuple) as you propose.


[builtins fixtures/tuple.pyi]
[out]
main: note: In function "f":
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use # flags: --hide-error-context to hide the function names. Then you can use # E: ... for multiple functions in a single test case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JukkaL Thanks for useful tip!

reveal_type(v) # E: Revealed type is 'builtins.int'
[builtins fixtures/tuple.pyi]
[out]
main: note: In function "tuplify":
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again this would be clearer if you'd use # flags: --hide-error-context. It should perhaps be on by default for test cases, but we have a huge number of test cases that would be affected so it's unclear whether it would be worth the code churn.

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 22, 2016

Looks good to merge, other than the above issues.

@ilevkivskyi
Copy link
Member Author

@JukkaL Thank you for review! I implemented your comments and added another small test that triggers the code for meet(Tuple[t1, t2], Tuple[s, ...]).

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 22, 2016

Looks good now. Thanks!

@JukkaL JukkaL merged commit 5f8c447 into python:master Nov 22, 2016
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

Successfully merging this pull request may close these issues.

isinstance checks don't work with tuple types Variable incorrectly typed as None, misleading error message
2 participants