
Monocle - An async programming framework with a blocking look-alike syntax - jperras
http://github.com/saucelabs/monocle#readme
======
vilya
Monocle seems nice enough, but the reliance on python's yield statement makes
it difficult to cleanly decompose your logic into functions. You can do it,
but you have to wrap each function call in a loop which re-yields each of the
values from the function. That seems a bit icky.

It'll get a bit nicer with the yield from statement described in PEP 380, but
it still means you have to have to prefix the function call - you can't just
call it normally and have it do the right thing.

What I really worry about though is that Python - at least for web development
- is becoming like Java, with frameworks to abstract over frameworks...

~~~
sah
I'm not sure I understand your concern here. How does monocle make decomposing
logic into functions difficult?

The "yield" keyword is an indicator of where control is returned back up to
the event loop and other things can happen. We like that in monocle, because
we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock
everything".

Eventlet (<http://eventlet.net/>) is an example of a similar framework that
decided not to require "yield" at these points.

~~~
vilya
Let me start by saying that I actually think Monocle is nice work given the
language mechanisms that Python provides and this is intended as constructive
criticism.

What I meant by "makes it hard" is that it creates two different calling
conventions for functions and you need to know how a function is implemented
to determine which one to use. Also, if the implementation of a function
changes you may need to find and change all the call sites of the function.
These are not insurmountable problems by any means, but they are extra
potential sources of error in a program.

I'm not familiar with Eventlet, but FWIW the Cocoon framework
(<http://cocoon.apache.org/>) had a quite nice take on this model back in the
day.

Hope that's useful.

------
risotto
The monocle decorator is really cute.

------
kevingadd
Reminds me of inlinecallbacks ([http://twistedmatrix.com/pipermail/twisted-
python/2007-Febru...](http://twistedmatrix.com/pipermail/twisted-
python/2007-February/014869.html)) and imvu.task
(<http://thespeedbump.livejournal.com/63798.html>).

Their Deferred type looks like it's not thread-safe or able to handle
reentrant invocations, which seems like it would limit the usefulness of this
framework in the real world, since many asynchronous APIs require you to be
able to handle being invoked from multiple threads.

------
pesco
Useful stuff, everyone should do it. In fact, I just did the same thing with
an event-driven GUI application in Ruby.

I'm wondering, it says it's designed to be portable between frameworks, how
much is actually framework-specific? Is there a useful library in there that's
completely agnostic to the surrounding event loop construction?

------
hanshasuro
Obligatory: <http://www.youtube.com/watch?v=js9d48G9HSI#t=0m27s>

~~~
pjy04
That's what I thought when I saw this thread

------
Sephr
There's a JavaScript library called async.js
(<http://github.com/eligrey/async.js>) that does that exact same thing
(pseudo-asynchronosity using the yield statement in decorated functions).

------
jacson
It seems as Monocle is somewhat equivalent to Swirl
(<http://code.naeseth.com/swirl/>), though Swirl is Tornado specific

------
denik
here's a library to do async concurrency in a synchronous way without yields
(using greenlets): <http://www.gevent.org>

------
chrisdew
Is this different to <http://code.google.com/p/cogen/> ?

