-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Covariance of Awaitable and friends #9812
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
Comments
Looking more closely, it appears that:
It does seem unfortunate that we cannot always convert Maybe at least |
That's not what happens at runtime, unfortunately. For a variety of reasons, it's good practice for typeshed to hew closely to runtime, rather than inventing fictional inheritance structures and method-resolution orders. |
I'm afraid I don't really see anything further we can do to improve the situation here, but I'm happy to reconsider if you have any specific suggestions :) |
Feel free to post example code that you wish type checked! |
Sure, this is a sketch of what I'm trying to do: async def get_int() -> int:
return 5
async def fun() -> None:
awaitables: set[typing.Awaitable[int]] = set(get_int() for _ in range(10))
while awaitables:
finished_tasks, awaitables = await asyncio.wait(
awaitables, return_when=asyncio.FIRST_COMPLETED
)
finished_results = await asyncio.gather(*finished_tasks)
print(finished_results) This results in an error on the line
|
In that case the variance of Awaitable and co wouldn't help you, since |
Yup, Jelle is correct. Consider using |
I see. Thanks folks! |
Shouldn't
typing.Awaitable
,asyncio.Task
,asyncio.Future
, etc., be covariant on their respective type paremeters?The text was updated successfully, but these errors were encountered: