[Python-Dev] Musings on concurrency and scoping ("replacing" Javascript)

[Phillip J. Eby]

At 07:04 PM 7/6/2006 -0500, Ka-Ping Yee wrote:
>On Thu, 6 Jul 2006, Phillip J. Eby wrote:
> > As much as I'd love to have the nested scope feature, I think it's only
> > right to point out that the above can be rewritten as something like this
> > in Python 2.5:
> >
> >      def spam():
> >          local_A = do_work()
> >          result_1 = yield do_network_transaction()
> >          local_B = do_work(result_1)
> >          result_2 = yield do_network_transaction()
> >          do_work(local_A, local_B, result_1, result_2)
> >          ...
> >
> > All you need is an appropriate trampoline (possibly just a decorator) that
> > takes the objects yielded by the function, and uses them up to set up
> > callbacks that resume the generator with the returned result.
>
>Clever!  Could you help me understand what goes on in
>do_network_transaction() when you write it this way?  In the
>Firefox/JavaScript world, the network transaction is fired off
>in another thread, and when it's done it posts an event back
>to the JavaScript thread, which triggers the callback.

The only difference here is that the callback is to the generator 
instance's send() method.  How the actual callback machinery works, and 
whether threads are involved are orthogonal to the code itself, making it 
an ideal implementation-independent way to express asynchronous algorithms.


>And what happens if you want to supply more than one continuation?
>In my JavaScript code i'm setting up two continuations per step --
>one for success and one for failure, since with a network you never
>know what might happen.

Errors can be passed back via the generator instance's throw() method.

See also peak.events (which could be considered a prototype implementation 
of PEP 342 and associated trampoline features) and Twisted's Deferred 
machinery (which allows sending either a result or a "failure" (where 
failures can be converted back into thrown exceptions).