-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Fix #1855: Multiassign from Union (take 2) #2219
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
Conversation
It's just getting uglier :| Using silenced period for the binder.
It's just getting uglier :| Using silenced period for the binder.
lr_pairs.append((star_lv.expr, rv_list)) | ||
lr_pairs.extend(zip(right_lvs, right_rvs)) | ||
for lv, rv in lr_pairs: | ||
self.check_assignment(lv, rv, infer_lvalue_type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing new in this function. It's only extracted, and the comment is slightly more elaborated.
@JukkaL I think I have addressed most of your comments from the original PR. Tell me if I'm missing anything. Also I am not confident with my "silence the binder" solution. I think it's ugly. |
Conflicts: mypy/binder.py
@elazarg This has been languishing for a month now. Do you still want to work on this? Despite what GitHub says, it actually requires help rebasing (I tried and failed -- maybe because there are so many small local commits). Maybe you can restart this work by separating it in two parts, one that just moves code around as you wish without any changes in behavior (as proved by passing all tests without any test editing) and then a second one that actually makes the small(ish) changes needed to fix the issue. |
I will make it merge-able after #2238 is merged, since both deal with the binder. |
Since @2238 is now merged, can you update this too? |
I should, but it's pretty invasive and old so it will be tricky. And perhaps I should take a fresh look at the whole thing. |
@elazarg Are you going to continue working on this? I think this is an important PR and I will be glad if it is finished. |
I tried, but the solutions I have in mind are too fundamental and will introduce too much churn. Sorry. |
Fixes #3859 Fixes #3240 Fixes #1855 Fixes #1575 This is a simple fix of various bugs and a crash based on the idea originally proposed in #2219. The idea is to check assignment for every item in a union. However, in contrast to #2219, I think it will be more expected/consistent to construct a union of the resulting types instead of a join, for example: ``` x: Union[int, str] x1 = x reveal_type(x1) # Revealed type is 'Union[int, str]' y: Union[Tuple[int], Tuple[str]] (y1,) = y reveal_type(y1) # Revealed type is 'Union[int, str]' ``` @elazarg did the initial work on this.
Reopening #2154. Fix #1855: the union case was simply not handled (Probably fixes #1575 too).
I moved some code around so the cases are syntactically together. It makes the diff harder to read; some functions are easier to read without the diff. Most of the actual content is
check_multi_assign_from_union()
The awkward part is the treatment of binding: I use a context manager to make the binding return a list of actions instead of doing the actual actions.