On Tue, Nov 8, 2016 at 12:43 PM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> > > 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. > But they could also call it before a loop is active and then call run_until_complete() on the thing. E.g. f = sleep1() # definition from my previous post asyncio.get_event_loop().run_until_complete(f) Assuming that's the only get_event_loop() call in the program, this will work if sleep1() is an actual coroutine or generator, but not if it returns a Future or Task. > 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? > I suppose, though that just complexifies it more. :-( It will solve the immediate issue being discussed here though. -- --Guido van Rossum (python.org/~guido)
