Remove unneeded Iterator base class from asyncio.Future

[tungol]

Taking another look, Awaitable is typed as Awaitable[_T_co] implies __await__(self) -> Generator[Any, Any, _T_co]: .... This is not quite an exact match for the stubs for asyncio.Future, which don't specify the covariant part, just def __await__(self) -> Generator[Any, None, _T]: .... I'm interested to see if that matters to mypy-primer or not.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[tungol]

A bit of churn above. It seems that Awaitable is required as a base class because it allows asyncio.Future to sometimes behave covariantly even though it's not typed as covariant itself.

I tested locally and could see that the mypy-primer results cleared up if the class was Future(Generic[_T_co]), so that definitely seems like the cause of the blow-up seen in #12818. With no way to make Future covariant directly, I believe Awaitable needs to stay.

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.

[hauntsaninja]

Yes, IIUC you would break the transitivity of subtyping. See also:

class A: ... class B(A): ... from typing import Sequence def takes_seq_a(x: Sequence[A]): ... def main(x: list[B]): takes_seq_a(x) 

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)