On 2016-11-08 3:29 PM, Guido van Rossum wrote:
I think the problem is that it's hard to tell the difference between these
two:
async def sleep1():
await asyncio.sleep(1)
def sleep1():
return Task(asyncio.sleep(1))
since both may be documented as being a "coroutine" but the latter
references the loop when you calls it, while the former only references the
loop when it's scheduled/awaited (because asyncio.sleep() is a generator).
And this is in turn because with a generator or coroutine, the body doesn't
execute when you call it -- but with something that returns a Future (or
Task), the body *does* execute in the call's context.
Right, but this is in part a documentation issue. If a library exposes
an API that documents some methods to be coroutines, when in fact they
return Future/Tasks, it means that the user is supposed to call this API
from a coroutine. In which case the updated get_event_loop() will do the
trick.
We should probably tell library authors to avoid returning tasks and
futures directly, instead preferring to wrap them in an actual
coroutine. What do you think about that?
I wanted Martin to clarify what does he do in his asyncio unittest
library -- what he tries to mock and why.
We should strive to make more things coroutines (though I'm not sure how to
turn gather() into a coroutine -- I recall it was complicated to write,
with the variant behaviors and possible timeouts or cancellations).
Can we rename asyncio.gather to asyncio._gather and wrap it into a
coroutine?
Yury
