Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75128 > unrolled thread

Re: Question about asyncio doc example

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about asyncio doc example Terry Reedy <tjreedy@udel.edu> - 2014-07-24 02:58 -0400
    Re: Question about asyncio doc example Marko Rauhamaa <marko@pacujo.net> - 2014-07-24 10:23 +0300
      Re: Question about asyncio doc example Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-24 10:46 -0600
        Re: Question about asyncio doc example Marko Rauhamaa <marko@pacujo.net> - 2014-07-24 20:07 +0300

#75128 — Re: Question about asyncio doc example

On 7/24/2014 1:15 AM, Saimadhav Heblikar wrote:
> On 24 July 2014 05:54, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 7/23/2014 6:43 AM, Saimadhav Heblikar wrote:
>>>
>>> Hi,
>>>
>>> The example in question is
>>>
>>> https://docs.python.org/3/library/asyncio-task.html#example-hello-world-coroutine.
>>> I'd like to learn the purpose of the statement
>>> "yield from asyncio.sleep(2)" in that example.
>>>
>>> In particular, I'd like to know if asyncio.sleep() is used as a
>>> substitute for slow/time consuming operation, i.e. in real code,
>>> whether there will be a real time consuming statement in place of
>>> asyncio.sleep().
>>
>>
>> The context is
>>      while True:
>>          print('Hello')
>>          yield from asyncio.sleep(3)
>>
>> sleep is both itself, to shown to schedule something at intervals in a
>> non-blocking fashion, as well as a placefiller.  The blocking equivalent
>> would use 'time' instead of 'yield from asyncio'. The following shows the
>> non-blocking feature a bit better.
>>
>> import asyncio
>>
>> @asyncio.coroutine
>> def hello():
>>      while True:
>>          print('Hello')
>>          yield from asyncio.sleep(3)
>>
>> @asyncio.coroutine
>> def goodbye():
>>      while True:
>>          print('Goodbye')
>>          yield from asyncio.sleep(5.01)
>>
>> @asyncio.coroutine
>> def world():
>>      while True:
>>          print('World')
>>          yield from asyncio.sleep(2.02)
>>
>> loop = asyncio.get_event_loop()
>> loop.run_until_complete(asyncio.wait([hello(), goodbye(), world()]))
>>
>> Getting the same time behavior in a while...sleep loop requires reproducing
>> some of the calculation and queue manipulation included in the event loop.
>>
>> --
>> Terry Jan Reedy
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
> That clears it up for me. For situations where I dont really know how
> long a function is going to take(say waiting for user input or a
> network operation), I am better off using callbacks than "yield from
> asyncio.sleep()". Is my understanding correct?

The question is not formulated very well. In asyncio parlance, 'using 
callbacks' contrasts with 'using co-routines'.  It is a coding-style 
contrast. Tkinter only has the callback style.

On the other hand, waiting (via sleep, without blocking other tasks) for 
a definite time interval contrasts with waiting (without blocking other 
tasks) until an event happens.  This is an operational contrast. Tkinter 
has both possibilities, using call_after versus event-handler 
registration.  I believe asyncio can do either type of waiting with 
either coding style.

18.5.3. Tasks and coroutines, seems to be devoid of event wait examples. 
However, there is a 'yield from' network example in 18.5.5 Streams using 
socket functions wrapped with coroutines. These should definitely be 
used instead of sleep. In fact, for cross-platform network code meant to 
run on *nix and Windows, they are better than the unix oriented select 
and poll functions.

I believe asyncio does not do key events, even though that is a form of 
unpredictable input.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#75131

Terry Reedy <tjreedy@udel.edu>:

> 18.5.3. Tasks and coroutines, seems to be devoid of event wait
> examples. However, there is a 'yield from' network example in 18.5.5
> Streams using socket functions wrapped with coroutines. These should
> definitely be used instead of sleep. In fact, for cross-platform
> network code meant to run on *nix and Windows, they are better than
> the unix oriented select and poll functions.

Asyncio has full support for the callback style as well. What I don't
know is how well the two styles mix. Say, you have a module that
produces callbacks and another one that is based on coroutines. The
coroutines can easily emit callbacks but can callbacks call "yield
from"?


Marko

[toc] | [prev] | [next] | [standalone]

#75152

[Multipart message — attachments visible in raw view] — view raw

On Jul 24, 2014 1:26 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>
> Terry Reedy <tjreedy@udel.edu>:
>
> > 18.5.3. Tasks and coroutines, seems to be devoid of event wait
> > examples. However, there is a 'yield from' network example in 18.5.5
> > Streams using socket functions wrapped with coroutines. These should
> > definitely be used instead of sleep. In fact, for cross-platform
> > network code meant to run on *nix and Windows, they are better than
> > the unix oriented select and poll functions.
>
> Asyncio has full support for the callback style as well. What I don't
> know is how well the two styles mix. Say, you have a module that
> produces callbacks and another one that is based on coroutines. The
> coroutines can easily emit callbacks but can callbacks call "yield
> from"?

Callbacks can easily schedule coroutines, but they can't wait on them,
because that would require suspending their execution, dropping back to the
event loop, and resuming later -- in other words, the callback would need
to be a coroutine also.

[toc] | [prev] | [next] | [standalone]

#75154

Ian Kelly <ian.g.kelly@gmail.com>:

> Callbacks can easily schedule coroutines, but they can't wait on them,
> because that would require suspending their execution, dropping back
> to the event loop, and resuming later -- in other words, the callback
> would need to be a coroutine also.

I guess the key is, can a callback release a lock or semaphore, notify a
condition variable, or put an item into a queue that a coroutine is
waiting on?

Quite possibly. Didn't try it. In that case, callbacks mix just fine
with coroutines.


Marko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web