-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Remove unneeded Iterator base class from asyncio.Future #12827
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
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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. 🤖🎉 |
A bit of churn above. It seems that Awaitable is required as a base class because it allows I tested locally and could see that the mypy-primer results cleared up if the class was Is it normal to have this kind of indirectly-covariant typing? I was surprised to find that it works that way, but I don't have a deep understanding of variance. |
Yes, IIUC you would break the transitivity of subtyping. See also:
asyncio.Future is mutable, so cannot be covariant: python/mypy#13689 (comment) (and if you want to break your brain a little bit, check out #8781 , which surfaced unsoundness and was patched in both pyright and mypy, see python/mypy#13714) |
Taking another look,
Awaitable
is typed asAwaitable[_T_co]
implies__await__(self) -> Generator[Any, Any, _T_co]: ...
. This is not quite an exact match for the stubs forasyncio.Future
, which don't specify the covariant part, justdef __await__(self) -> Generator[Any, None, _T]: ...
. I'm interested to see if that matters to mypy-primer or not.