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.
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 si
On 2014-01-07 02:29, Cameron Simpson wrote:
On 06Jan2014 18:56, Skip Montanaro 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 percei
>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 mann
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 nee
On 06Jan2014 18:56, Skip Montanaro 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
> cancel (as perceive
On 2014-01-07 00:56, Skip Montanaro wrote:
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
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
t
