Skip to content

Iterate on ItemsView and KeysView #3181

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 7 commits into from
Sep 5, 2019

Conversation

kaste
Copy link
Contributor

@kaste kaste commented Aug 13, 2019

  • IMO all dunder operators herein construct proper Sets
  • __sub__ aka - aka difference return the Left not a union (this also matches the implementation of AbstractSet
  • __and__ aka & aka intersection also returns Left. This is also consistent with AbstractSet and Set

Related python/mypy#7236

Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

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

Sorry for the late reply and thank you for the PR. Remarks below.

@srittau
Copy link
Collaborator

srittau commented Sep 3, 2019

In reference to #3184: Let's make this consistent for the annotation of set for now. When we decide to make set() more strict, we can change it later.

Co-Authored-By: Sebastian Rittau <srittau@rittau.biz>
@kaste
Copy link
Contributor Author

kaste commented Sep 5, 2019

I just applied the suggestions you made. But just wait a minute: I used Iterable[T] probably because lazy, but I would have used Iterable[Any] (or maybe just Iterable) in my own code. Is there a difference? I never used Something[object], I sometimes use an unbound T, mypy doesn't complain here, and I thought it will substitute something like Any in such cases. But here in this codebase, set always references AbstractSet[object] in such cases, but Iterable[Any] if Iterable is used. 😕

@srittau
Copy link
Collaborator

srittau commented Sep 5, 2019

I think an unbound type var is basically equivalent to Any, but less obvious. The difference between object and Any for argument types is largely academic: object implies that literally anything can used here, while Any says that the expected type can't be expressed adequately with the current type system. For example, str() could be annotated as str(o: object) -> str, since anything can be converted to a string. (It's a class in reality, though.)

@srittau srittau merged commit 668988f into python:master Sep 5, 2019
@kaste
Copy link
Contributor Author

kaste commented Sep 5, 2019

Thanks for explaining.

@kaste kaste deleted the iterate-on-mappingviews branch September 5, 2019 15:03
msullivan added a commit that referenced this pull request Oct 2, 2019
This was discussed in #3181 and the correct explanation was given that
object ought to be preferred here. In practice this caused an obscure
issue with mypy when using this operations on the results of
six.viewkeys(), since it decided that it wanted a mapping *from* object
as a result of inference contexts. Grumble.
srittau pushed a commit that referenced this pull request Oct 2, 2019
…3294)

This was discussed in #3181 and the correct explanation was given that
object ought to be preferred here. In practice this caused an obscure
issue with mypy when using this operations on the results of
six.viewkeys(), since it decided that it wanted a mapping *from* object
as a result of inference contexts. Grumble.
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.

2 participants