Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CANc-5UzZj9vNdZVvDNosaGaOLXhOykagF_HkqafYjnoNguD2Mw@mail.gmail.com>
References: <CANc-5UzZj9vNdZVvDNosaGaOLXhOykagF_HkqafYjnoNguD2Mw@mail.gmail.com>
Date: Mon, 6 Jan 2014 18:56:00 -0600
Subject: Trying to wrap my head around futures and coroutines
From: Skip Montanaro <skip.montanaro@gmail.com>
To: Python <python-list@python.org>
Content-Type: multipart/alternative; boundary=089e01184b0c03546104ef56d7f3
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5101.1389056164.18130.python-list@python.org>
Lines: 149
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63389

--089e01184b0c03546104ef56d7f3
Content-Type: text/plain; charset=UTF-8

I've been programming for a long while in an event&callback-driven world.
While I am comfortable enough with the mechanisms available (almost 100% of
what I do is in a PyGTK world with its signal mechanism), it's never been
all that satisfying, breaking up my calculations into various pieces, and
thus having my algorithm scattered all over the place.

So, I'm looking for a little guidance. It seems to me that futures,
coroutines, and/or the new Tulip/asyncio package might be my salvation, but
I'm having a bit of trouble seeing exactly how that would work. Let me
outline a simple hypothetical calculation. I'm looking for ways in which
these new facilities might improve the structure of my code.

Let's say I have a dead simple GUI with two buttons labeled, "Do A" and "Do
B". Each corresponds to executing a particular activity, A or B, which take
some non-zero amount of time to complete (as perceived by the user) or
cancel (as perceived by the state of the running system - not safe to run A
until B is complete/canceled, and vice versa). The user, being the fickle
sort that he is, might change his mind while A is running, and decide to
execute B instead. (The roles can also be reversed.) If s/he wants to run
task A, task B must be canceled or allowed to complete before A can be
started. Logically, the code looks something like (I fear Gmail is going to
destroy my indentation):

def do_A():
when B is complete, _do_A()
cancel_B()

def do_B():
when A is complete, _do_B()
cancel_A()

def _do_A():
do the real A work here, we are guaranteed B is no longer running

def _do_B():
do the real B work here, we are guaranteed A is no longer running

cancel_A and cancel_B might be no-ops, in which case they need to start up
the other calculation immediately, if one is pending.

This is pretty simple execution, and if my job was this simple, I'd
probably just keep doing things the way I do now, which is basically to
catch a "complete" or "canceled" signal from the A and B tasks and execute
the opposite task if it's pending. But it's not this simple. In reality
there are lots of, "oh, you want to do X? You need to make sure A, B, and C
are not active." And other stuff like that.

I have this notion that I should be able to write do_A() something like
this:

def do_A():
cancel_B()
yield from ... ???
_do_A()
...

or

def do_A():
future = cancel_B()
future.on_completion(_do_A)
... or ???

with the obvious similar structure for do_B. To my mind's eye, the first
option is preferable, since it's obvious that when control reaches the line
after the yield from statement, it's fine to do the guts of task A.

So, is my simpleminded view of the world a possibility with the current
facilities available in 3.3 or 3.4?

Thx,

Skip

--089e01184b0c03546104ef56d7f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I&#39;ve been programming for a long while in an event&amp;c=
allback-driven world. While I am comfortable enough with the mechanisms ava=
ilable (almost 100% of what I do is in a PyGTK world with its signal mechan=
ism), it&#39;s never been all that satisfying, breaking up my calculations =
into various pieces, and thus having my algorithm scattered all over the pl=
ace.</p>

<p dir=3D"ltr">So, I&#39;m looking for a little guidance. It seems to me th=
at futures, coroutines, and/or the new Tulip/asyncio package might be my sa=
lvation, but I&#39;m having a bit of trouble seeing exactly how that would =
work. Let me outline a simple hypothetical calculation. I&#39;m looking for=
 ways in which these new facilities might improve the structure of my code.=
</p>

<p dir=3D"ltr">Let&#39;s say I have a dead simple GUI with two buttons labe=
led, &quot;Do A&quot; and &quot;Do B&quot;. Each corresponds to executing a=
 particular activity, A or B, which take some non-zero amount of time to co=
mplete (as perceived by the user) or cancel (as perceived by the state of t=
he running system - not safe to run A until B is complete/canceled, and vic=
e versa). The user, being the fickle sort that he is, might change his mind=
 while A is running, and decide to execute B instead. (The roles can also b=
e reversed.) If s/he wants to run task A, task B must be canceled or allowe=
d to complete before A can be started. Logically, the code looks something =
like (I fear Gmail is going to destroy my indentation):</p>

<p dir=3D"ltr">def do_A():<br>
when B is complete, _do_A()<br>
cancel_B()</p>
<p dir=3D"ltr">def do_B():<br>
when A is complete, _do_B()<br>
cancel_A()</p>
<p dir=3D"ltr">def _do_A():<br>
do the real A work here, we are guaranteed B is no longer running</p>
<p dir=3D"ltr">def _do_B():<br>
do the real B work here, we are guaranteed A is no longer running</p>
<p dir=3D"ltr">cancel_A and cancel_B might be no-ops, in which case they ne=
ed to start up the other calculation immediately, if one is pending.</p>
<p dir=3D"ltr">This is pretty simple execution, and if my job was this simp=
le, I&#39;d probably just keep doing things the way I do now, which is basi=
cally to catch a &quot;complete&quot; or &quot;canceled&quot; signal from t=
he A and B tasks and execute the opposite task if it&#39;s pending. But it&=
#39;s not this simple. In reality there are lots of, &quot;oh, you want to =
do X? You need to make sure A, B, and C are not active.&quot; And other stu=
ff like that.</p>

<p dir=3D"ltr">I have this notion that I should be able to write do_A() som=
ething like this:</p>
<p dir=3D"ltr">def do_A():<br>
cancel_B()<br>
yield from ... ???<br>
_do_A()<br>
...</p>
<p dir=3D"ltr">or</p>
<p dir=3D"ltr">def do_A():<br>
future =3D cancel_B()<br>
future.on_completion(_do_A)<br>
... or ???</p>
<p dir=3D"ltr">with the obvious similar structure for do_B. To my mind&#39;=
s eye, the first option is preferable, since it&#39;s obvious that when con=
trol reaches the line after the yield from statement, it&#39;s fine to do t=
he guts of task A.</p>

<p dir=3D"ltr">So, is my simpleminded view of the world a possibility with =
the current facilities available in 3.3 or 3.4?</p>
<p dir=3D"ltr">Thx,</p>
<p dir=3D"ltr">Skip</p>

--089e01184b0c03546104ef56d7f3--