Message352843
I think `func.__awaitable__ = True` can serve all possible situations.
We need it for async mocks (now the library use flawless `_is_coroutine` approach.
`__awaitable__` can also cover cases where a regular function returns awaitable object or there is a class with `def __await__(self)` method, `functools.partial` -- all of them are awaitable.
Async functions can be modified to provide the property out of the box.
Regarding the question "is a check for awaitableness a good design or not"?
I agree that a check for awaitableness is useless *just before* calling the function.
There is another very useful case where the check is important: registering a callback for later usage.
For example, we have a web server framework. It is built around a mapping of URL paths to async functions, e.g. path('/hello', say_hello) in Django style. It's crucial to check if say_hello() is an async function *on the application configuration stage*, not on viewing the particular http://localhost/hello page in a browser.
So, I think an official protocol makes a lot of sense, let's implement it in 3.9 |
|
Date |
User |
Action |
Args |
2019-09-20 08:47:04 | asvetlov | set | recipients:
+ asvetlov, scoder, yselivanov, dhiltonp |
2019-09-20 08:47:04 | asvetlov | set | messageid: <1568969224.46.0.896028788279.issue38225@roundup.psfhosted.org> |
2019-09-20 08:47:04 | asvetlov | link | issue38225 messages |
2019-09-20 08:47:04 | asvetlov | create | |
|