Skip to content

bpo-28556: Don't simplify unions at runtime #6841

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 4 commits into from
May 18, 2018

Conversation

ilevkivskyi
Copy link
Member

@ilevkivskyi ilevkivskyi commented May 14, 2018

Copy link
Contributor

@grimreaper grimreaper left a comment

Choose a reason for hiding this comment

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

The change itself looks find to me, but its not clear that changing this is the right thing to do. As a general note we're removing old explicit logic and tests rather than just fixing a bug. I didn't notice any discussion of the issue on the mailing list or otherwise. Feel free to direct me if I missed it.

@ilevkivskyi
Copy link
Member Author

The change itself looks find to me, but its not clear that changing this is the right thing to do. As a general note we're removing old explicit logic and tests rather than just fixing a bug. I didn't notice any discussion of the issue on the mailing list or otherwise. Feel free to direct me if I missed it.

Some people see this as a bug, see example in the issue linked above. Also this code was a bug magnet because it needs to use issubclass() which is prohibited for various special types.

@ilevkivskyi
Copy link
Member Author

@gvanrossum Sorry for being annoying, but if we want to get this in 3.7 we only have time until Monday. Could you please briefly take a look at this PR?

@gvanrossum
Copy link
Member

No worries. I'll try to review later today.

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

A few nits about tests; the substance of the code LGTM. (Nice that it was such a clear separate bit of code. :-)

self.assertEqual(u, object)
u1 = Union[int, object]
u2 = Union[object, int]
self.assertEqual(u1, u2)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe also assert that it isn't object?

u = Union[Employee, Manager]
self.assertIs(u, Employee)
self.assertIsNot(u, Employee)
Copy link
Member

Choose a reason for hiding this comment

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

Can you check that Employee and Manager are both members of the union?

@@ -317,7 +312,6 @@ def test_cannot_instantiate(self):
def test_union_generalization(self):
self.assertFalse(Union[str, typing.Iterable[int]] == str)
self.assertFalse(Union[str, typing.Iterable[int]] == typing.Iterable[int])
self.assertTrue(Union[str, typing.Iterable] == typing.Iterable)
Copy link
Member

Choose a reason for hiding this comment

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

How about a more positive test of the expected members?

Lib/typing.py Outdated
@@ -203,7 +203,7 @@ def _check_generic(cls, parameters):

def _remove_dups_flatten(parameters):
"""An internal helper for Union creation and substitution: flatten Union's
Copy link
Member

Choose a reason for hiding this comment

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

Union's -> Unions

@ilevkivskyi
Copy link
Member Author

@gvanrossum Thanks for review! I addressed all comments, plus I think there is one important point to add: this change breaks semantics of __eq__, now Union[Manager, Employee] != Employee. I can tweak __eq__, but the problem is that generics are cashed, so after once writing List[Employee], then writing List[Union[Manager, Employee]] will return List[Employee] thus again effectively simplifying a union.

@gvanrossum
Copy link
Member

this change breaks semantics of eq, now Union[Manager, Employee] != Employee. I can tweak eq, but the problem is that generics are cashed, so after once writing List[Employee], then writing List[Union[Manager, Employee]] will return List[Employee] thus again effectively simplifying a union.

Sorry, the tenses are confusing. Is the problem with List[Union[Manager, Employee]] returning List[Employee] happening with this version of the PR or would that happen if you "tweaked" __eq__?

Honestly given that we don't simplify unions I think it's right that Union[Manager, Employee] != Employee.

@gvanrossum
Copy link
Member

Also I think this requires a news item.

@ilevkivskyi
Copy link
Member Author

Honestly given that we don't simplify unions I think it's right that Union[Manager, Employee] != Employee.

OK, This is what happens with this PR, the problem I described would will appear only if I will tweak __eq__.

Also I think this requires a news item.

OK, I will add it.

@ilevkivskyi ilevkivskyi changed the title Don't simplify unions at runtime bpo-28556: Don't simplify unions at runtime May 18, 2018
@ilevkivskyi
Copy link
Member Author

asyncio failures are unrelated/flakes.

@ilevkivskyi
Copy link
Member Author

I will close and re-open to trigger AppVeyor.

@ilevkivskyi ilevkivskyi reopened this May 18, 2018
@ilevkivskyi
Copy link
Member Author

Restarting AppVeyor again...

@ilevkivskyi ilevkivskyi reopened this May 18, 2018
Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

You have to merge this manually because the VSTS tests always fail (they are non-blocking, but Miss Islington doesn't know).

@ilevkivskyi
Copy link
Member Author

You have to merge this manually because the VSTS tests always fail (they are non-blocking, but Miss Islington doesn't know).

OK, I see. Will do this now.

@ilevkivskyi ilevkivskyi merged commit f65e31f into python:master May 18, 2018
@miss-islington
Copy link
Contributor

Thanks @ilevkivskyi for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

@ilevkivskyi ilevkivskyi deleted the no-simplify-union branch May 18, 2018 23:00
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request May 18, 2018
(cherry picked from commit f65e31f)

Co-authored-by: Ivan Levkivskyi <[email protected]>
@bedevere-bot
Copy link

GH-6979 is a backport of this pull request to the 3.7 branch.

ilevkivskyi added a commit that referenced this pull request May 18, 2018
(cherry picked from commit f65e31f)

Co-authored-by: Ivan Levkivskyi <[email protected]>
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.

6 participants