Re: Trying to wrap my head around futures and coroutines

2014-01-15 Thread Phil Connell
On Mon, Jan 06, 2014 at 06:56:00PM -0600, Skip Montanaro wrote: 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

Re: Trying to wrap my head around futures and coroutines

2014-01-15 Thread Oscar Benjamin
On Mon, Jan 06, 2014 at 09:15:56PM -0600, Skip Montanaro wrote: From the couple responses I've seen, I must have not made myself clear. Let's skip specific hypothetical tasks. Using coroutines, futures, or other programming paradigms that have been introduced in recent versions of Python 3.x,

Trying to wrap my head around futures and coroutines

2014-01-06 Thread Skip Montanaro
I've been programming for a long while in an eventcallback-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

Re: Trying to wrap my head around futures and coroutines

2014-01-06 Thread MRAB
On 2014-01-07 00:56, Skip Montanaro wrote: I've been programming for a long while in an eventcallback-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

Re: Trying to wrap my head around futures and coroutines

2014-01-06 Thread Cameron Simpson
On 06Jan2014 18:56, Skip Montanaro skip.montan...@gmail.com wrote: [...] 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

Re: Trying to wrap my head around futures and coroutines

2014-01-06 Thread Cameron Simpson
On 07Jan2014 13:29, I wrote: def do_A(): with lock_B(): with lock_A(): _do_A() Um, of course there would be a cancel_B() up front above, like this: def do_A(): cancel_B() with lock_B(): with lock_A(): _do_A() I'm with MRAB: you don't really need

Re: Trying to wrap my head around futures and coroutines

2014-01-06 Thread Skip Montanaro
From the couple responses I've seen, I must have not made myself clear. Let's skip specific hypothetical tasks. Using coroutines, futures, or other programming paradigms that have been introduced in recent versions of Python 3.x, can traditionally event-driven code be written in a more linear

Re: Trying to wrap my head around futures and coroutines

2014-01-06 Thread MRAB
On 2014-01-07 02:29, Cameron Simpson wrote: On 06Jan2014 18:56, Skip Montanaro skip.montan...@gmail.com wrote: [...] 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