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

Allow unpacking from TypeVars with iterable bounds #13425

Merged
merged 3 commits into from Aug 19, 2022

Conversation

tdsmith
Copy link
Contributor

@tdsmith tdsmith commented Aug 15, 2022

Description

TypeVars aren't iterable, but their bounds might be! Resolve a TypeVar to its bounds before trying to decide how to unpack one of its instances. This allows unpacking from instances of TypeVars with iterable bounds, which otherwise fails.

Fixes #13402.

Test Plan

Added a test for a minimal reproducer.

TypeVars aren't iterable, but their bounds might be!
Resolve a TypeVar to its bounds before trying to decide how to unpack
one of its instances.

Fixes python#13402.
@github-actions

This comment has been minimized.

from typing import Tuple, TypeVar
TupleT = TypeVar("TupleT", bound=Tuple[int, ...])
def f(t: TupleT) -> None:
a, *b = t
Copy link
Member

Choose a reason for hiding this comment

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

Let's add reveal_type(a) and reveal_type(b) here. This would catch some unexpected types.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

@@ -3168,6 +3168,9 @@ def check_multi_assignment(
# TODO: maybe elsewhere; redundant.
rvalue_type = get_proper_type(rv_type or self.expr_checker.accept(rvalue))

if isinstance(rvalue_type, TypeVarType):
rvalue_type = get_proper_type(rvalue_type.upper_bound)
Copy link
Member

Choose a reason for hiding this comment

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

What if there's no upper bound? 🤔 Let's add a test case for this as well!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good thing to check 😅 It looks like it does the right thing!

I left the first test case in check-bound.test and added the new test case to check-typevar-unbound.test but let me know if they should be organized differently.

Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

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

Thank you!

@github-actions

This comment has been minimized.

@tdsmith
Copy link
Contributor Author

tdsmith commented Aug 17, 2022

Thanks for your help!

@github-actions

This comment has been minimized.

1 similar comment
@github-actions
Copy link
Contributor

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@sobolevn sobolevn merged commit 7d95e2e into python:master Aug 19, 2022
@tdsmith tdsmith deleted the iterable-typevar-unpacking branch August 22, 2022 15:24
hauntsaninja pushed a commit to hauntsaninja/mypy that referenced this pull request Sep 10, 2022
* Allow unpacking from TypeVars by resolving bounds

TypeVars aren't iterable, but their bounds might be!
Resolve a TypeVar to its bounds before trying to decide how to unpack
one of its instances.

Fixes python#13402.
hauntsaninja added a commit that referenced this pull request Sep 12, 2022
…13425) (#13644)

TypeVars aren't iterable, but their bounds might be! Resolve a TypeVar
to its bounds before trying to decide how to unpack one of its
instances.

Fixes #13402

Co-authored-by: Tim D. Smith <github@tim-smith.us>
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.

Instances of type variables bounded by an iterable type support iteration but not unpacking
2 participants