-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Update comments for operator.itemgetter.__call__ generic following mypy 1.11 fix
#13489
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
Update comments for operator.itemgetter.__call__ generic following mypy 1.11 fix
#13489
Conversation
operator.itemgetter generic following mypy 1.11 fix
…-fix' of https://github.com/Avasam/typeshed into Improve-operator.itemgetter-generic-following-mypy-1.11-fix
This comment has been minimized.
This comment has been minimized.
|
There seems to be a variance issue in the interaction with |
This comment has been minimized.
This comment has been minimized.
operator.itemgetter generic following mypy 1.11 fixoperator.itemgetter.__call__ generic following mypy 1.11 fix
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I'm also not sure why this doesn't work. Still I think for now it's best to postpone (i.e. close) this PR, until this works better. |
|
If you close this, please make it an issue. The behaviour here feels unexpected and seems worth investigating. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…e-operator.itemgetter-generic-following-mypy-1.11-fix
This comment has been minimized.
This comment has been minimized.
stdlib/operator.pyi
Outdated
| # preventing [_T_co, _T] instead of [Any, _T] | ||
| def __call__(self, obj: SupportsGetItem[Any, _T]) -> _T: ... |
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.
I don't mind abandoning the changes of this PR if I can at least update the reason why we have to keep def __call__(self, obj: SupportsGetItem[Any, Any]) -> Any: ..., given that python/mypy#14032 is closed as completed.
I just don't fully understand what's the issue at hand.
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.
This could be a variance issue. SupportsGetItem's second type var is covariant, while _T is invariant. Maybe introduce a _T1_co type var and try to use that instead?
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.
I took another look at it, and I think I understand my main issue: There's no way to preserve the itemgetter typevar as a literal
itemgetter(0) should be a itemgetter[Literal[0]] but type-checkers understand it as a is a itemgetter[int].
groupby iterates tuples (tuple[_T_co, Iterator[_S_co]]). But there's no way afaik to use map(operator.itemgetter(0), groupby(iterable)) such that type checkers know that it returns a map of the first element (map[_T_co] and not map[_T_co | Iterator[_S_co]])
(I think getter: operator.itemgetter[Literal[0]] = operator.itemgetter(0) technically works, but it's even more verbose and you still deal with variance issues with groupby anyway)
operator.itemgetter.__call__ generic following mypy 1.11 fixoperator.itemgetter.__call__ generic following mypy 1.11 fix
This comment has been minimized.
This comment has been minimized.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
python/mypy#14032 has been fixed in mypy 1.11.0 (I didn't go as far as to search for the exact commit).
This
updatesadds a comment explaining why we still can't do that change, and adds a regression test.operator.itemgetterto include a change I originally wanted to do in #9117, removes the outdated comment,