Ok, I see. Maybe the stop function should raise an exception if called on a loop that is not running?
Calling async.sleep(0) to flush remaining callbacks on a loop about to be closed works for me now, but maybe something like loop.flush() that runs the loop and calls all remaining callbacks() would be more clear. Or, to avoid bloating the API, why not let loop.run_until_complete() accept an empty argument list and behave in the same way? Anyway, thanks for the clarification. Adding something along the lines of what you just wrote to the module docs would probably make it less likely to be misunderstood. Den tisdagen den 1:e april 2014 kl. 11:28:51 UTC+11 skrev Guido van Rossum: > > I think there may be some ambiguity in the wording. :-( > > The intention is that you should call stop() from *inside* the loop, i.e. > when it is already running. It seems you interpreted the docs to mean that > stop() itself runs the remaining callbacks. That is not the case -- it > merely tells a running loop to stop. > > How could we have made this clearer in the docs? > > > On Mon, Mar 31, 2014 at 4:55 PM, Lars Andersson <[email protected]<javascript:> > > wrote: > >> Hi, >> >> I'm a bit confused by the behaviour of loop.stop() >> >> The asyncio docs states that: >> >> "Every callback scheduled before >> stop()<https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.stop> >> is >> called will run." >> >> Still, when running asyncio from python3.4 on OS X 10.9.2, the following >> program does not end up calling the callback() function: >> >> import asyncio >> >> def callback(): >> print("CALLBACK CALLED") >> >> loop = asyncio.get_event_loop() >> loop.call_soon(callback) >> #loop.run_until_complete(asyncio.sleep(0)) >> loop.stop() >> >> >> Uncommenting the line calling asyncio.sleep(0) seems to fix the problem, >> and the callback is actually called. Is this expected behaviour? >> >> > > > -- > --Guido van Rossum (python.org/~guido) >
