Skip to content
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

Error on call to asyncio.gather() with arguments of different types #675

Closed
JelleZijlstra opened this issue Nov 10, 2016 · 3 comments
Closed

Comments

@JelleZijlstra
Copy link
Member

In mypy, the following code:

import asyncio


async def f() -> int:
    return 3


async def g() -> str:
    return ''


async def h() -> None:
    x, y = await asyncio.gather(f(), g())  # type: int, str

produces the error:

gather.py: note: In function "h":
gather.py:13: error: Cannot infer type argument 1 of "gather"

(regardless of whether the type error on the last line is present)

This is on the latest release of mypy with the git HEAD version of typeshed (the released mypy has an old version of typeshed that doesn't support gather() at all).

I think this is a typeshed issue, not a mypy issue, but I'm not sure how the type of this function should be expressed instead. The current annotation for gather() is:

def gather(*coros_or_futures: Union[Future[_T], Generator[Any, None, _T], Awaitable[_T]],
           loop: AbstractEventLoop = ..., return_exceptions: bool = False) -> Future[List[_T]]: ...
@gvanrossum
Copy link
Member

@sixolet: Here's another example for variadic type variables.

@JelleZijlstra: Since we don't have variadic type variables yet, I think the only way to fix the stub for now is to use Any instead of _T, but this loses type-safety. Or you could add # type: ignore and you'd still lose type-safety but at least we'd have type-safety in case all coroutines passed return the same type of value.

Do you have a preference?

@JelleZijlstra
Copy link
Member Author

I did solve my issue for now with # type: ignore, but don't have a strong opinion on what typeshed should do here. In general it seems better to err on the side of using Any where a more specific type could lead to false positive errors (similar to #285), but I'll leave that judgment to you.

@gvanrossum
Copy link
Member

OK, I'll use Any.

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

No branches or pull requests

2 participants