The class asyncio.Runner currently checks explicitly that its coro argument is a coroutine:
|
"""Run a coroutine inside the embedded event loop.""" |
|
if not coroutines.iscoroutine(coro): |
|
raise ValueError("a coroutine was expected, got {!r}".format(coro)) |
However, shouldn't this allow any awaitable, checked via inspect.isawaitable(), or perhaps aligned with run_until_complete(), which currently accepts a Future object? Is there a specific reason why only coroutines are allowed here?
I've got a class which implements a custom __await__() method that I'd like to be able to pass into asyncio.Runner, but the check above is preventing this. There are workaround for this, like wrapping the await on the object in a regular async function, but I'd prefer not to require that.
Linked PRs
The class
asyncio.Runnercurrently checks explicitly that its coro argument is a coroutine:cpython/Lib/asyncio/runners.py
Lines 87 to 89 in 46e69f8
However, shouldn't this allow any awaitable, checked via
inspect.isawaitable(), or perhaps aligned withrun_until_complete(), which currently accepts a Future object? Is there a specific reason why only coroutines are allowed here?I've got a class which implements a custom
__await__()method that I'd like to be able to pass into asyncio.Runner, but the check above is preventing this. There are workaround for this, like wrapping the await on the object in a regular async function, but I'd prefer not to require that.Linked PRs
asyncio.runners.Runnerto run an awaitable object. #120306