I fully agree about coroutines, one thing though: I often see functions returning awaitables documented as "coroutines", and I see that as a problem since it gives the assumption that it won't be executed until processed by the loop.
For instance, asynctest can't identify them as coroutines, they won't get mocked correctly: it used to be the case with aiohttp (until the wrapper class was added to the asyncio.COROUTINE_TYPES list for python 3.5): https://github.com/Martiusweb/asynctest/issues/23 In asyncio, it is still the case from some primitives of the loop (run_in_executor(), getaddrinfo()), since they are methods of the loop instance, I guess it's fine. 2016-11-08 19:18 GMT+01:00 Yury Selivanov <yselivanov...@gmail.com>: > > > On 2016-11-08 11:07 AM, Martin Richard wrote: > >> - the feature is left as it is: a library author should no longer have to >> deal with the loop from a coroutine/a callback, and this is how asyncio >> libraries should be written. >> >> > ^- this. To add to what Guido said, I think we should promote > coroutine-centric APIs for libraries. > > I.e. a library should expose API as coroutines that don't even accept the > loop parameter. > > Yury > -- Martin <http://www.martiusweb.net> Richard www.martiusweb.net
