-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Question regarding Coroutine vs Awaitable #4460
Comments
I think this is a bug in mypy. Adding This might be fairly easy to fix—if you are able to, feel free to submit a PR to fix the issue. |
The tricky thing is that Edit: I tried to have a look around the codebase and see if I can figure out what would need changing but it's all a bit too complicated for me, so unfortunately I think I cannot fix this myself at the moment. |
* Change the return type of coroutine functions to coroutine object Previously, the return type was `Awaitable`, which is correct, but not specific enough for some use cases. For example, if you have a function parameter that should be a coroutine object (but not a `Future`, `Task` or other awaitable), then `mypy` is unable to detect incorrect invocations of the function. This change is (deliberately) imcomplete as is. It seems like this breaks quite a few tests in `mypy`. The first symptom is that coroutine objects are now (incorrectly) detected as generators.. * Prevent coroutine functions from being classified as generators This change removes the undesired "return type of a generator function should be `Generator` or one of its subtypes for coroutine function definitions. However, it introduces a new error where the return type of coroutine functions is expected to be `Coroutine[T, Any, Any]` instead of the desired `T`. It looks like we were hijacking a generator-specific path for checking the return type of coroutine functinos. I added an explicit path for coroutine functions, allowing our test to pass. However, lots of tests now fail. A few of them were simply places that were incidentally relying on coroutine functions to have type `Awaitable`. I fix them. The remaining failures all seem to be about coroutine functions with return type `None` without an explicit return statement. Seems like this is also something for which we were relying on implicit classification as generators. * Allow implicit return for coroutine functions that return `None` Most of the tests are fixed, but two tests still fail. One about not detecting invalid `yield from` on `AwaitableGenerator`. The other about types being erased in call to `asyncio.gather()`. * Fix return type for coroutine functions decorated with @coroutine * Fix detection of await expression on direct coroutine function call Changing the return type of coroutine functions to `Coroutine` introduced a regression in the expression checks. * Fix regression after change of coroutine function return type * Fix position of return type in `Coroutine` This fixes the type inference logic that was causing the last failing test to fail. Build should now be green :-) * Fix issues raised in code review Fixes #3569. Fixes #4460. Special thanks to @ilevkivskyi and @gvanrossum for their time and their infinite patience with all my questions :-)
Given this code:
Versions:
Running
mypy --strict script.py
I getscript.py:24: error: Argument 1 to "add_task" has incompatible type "Awaitable[None]"; expected "Coroutine[Any, None, Any]"
, but changingTask
toAwaitable[None]
gives mescript.py:19: error: "Awaitable[None]" has no attribute "send"
. The code runs fine though.What would be the proper type hints in this scenario?
The text was updated successfully, but these errors were encountered: