Skip to content

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

Closed
wants to merge 30 commits into from

Conversation

elazarg
Copy link
Contributor

@elazarg elazarg commented Oct 5, 2016

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.

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)
Copy link
Contributor Author

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.

@elazarg
Copy link
Contributor Author

elazarg commented Oct 7, 2016

@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.

@gvanrossum gvanrossum changed the title Fix #1855: Multiassign from Union (take 2) [waiting for reviewer] Fix #1855: Multiassign from Union (take 2) Oct 17, 2016
@gvanrossum gvanrossum changed the title [waiting for reviewer] Fix #1855: Multiassign from Union (take 2) Fix #1855: Multiassign from Union (take 2) Oct 17, 2016
@gvanrossum
Copy link
Member

@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.

@elazarg
Copy link
Contributor Author

elazarg commented Nov 9, 2016

I will make it merge-able after #2238 is merged, since both deal with the binder.

@gvanrossum
Copy link
Member

Since @2238 is now merged, can you update this too?

@elazarg
Copy link
Contributor Author

elazarg commented Mar 27, 2017

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 elazarg closed this May 10, 2017
@ilevkivskyi
Copy link
Member

ilevkivskyi commented May 10, 2017

@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.

@elazarg
Copy link
Contributor Author

elazarg commented May 11, 2017

I tried, but the solutions I have in mind are too fundamental and will introduce too much churn. Sorry.

JukkaL pushed a commit that referenced this pull request Oct 11, 2017
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.
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.

error: 'Union[Any, Tuple[Any, Any]]' object is not iterable
3 participants