Agreed - they seem similar (monocle can even use twisted's reactor). But then I have some personal issues with twisted. IMHO it's simply not well organised. Every time I wrote something, I had to browse through the long list of classes in the API documentation to find what I need (and wonder about how many kinds of reactors are actually needed, and why are they split across so many modules, and ...). The way the docs are written also makes it not very inviting for new users (some pages just seem to say "here, yield does magic").

I chose diesel over twisted many times, simply because of how it's organised, but then again sometimes I had to use twisted, since diesel didn't have some features.

Monocle looks nice to me. If it does the same things twisted offers, I'll choose monocle. Then again, that was a very subjective opinion.

Well, monocle is headed in its own direction. We're abstracting the generator-style concurrency stuff out from the underlying I/O framework, so monocle works with both Twisted and Tornado, and we're prepared to interoperate with other frameworks in the future. On top of that base, we're developing a framework for working in this style; there are some early ideas in monocle.experimental. We're also building simplified base networking APIs in a way that only makes sense if you're committed to this style of concurrency.

I think the question is really whether you're more compelled by generator-style concurrency, or Twisted itself. If you want to work deeply with Twisted, inlineCallbacks lets you use generator-style where you want, and is maintained along with Twisted. If you want to use generator-style concurrency to its full advantage in simplifying complex evented servers, that's where monocle is going.

Monocle works by wrapping a single generator and translating each yield-statement into a hand-off to the event loop or reactor and resuming when the value of the deferred becomes known.

Since the code is confined to a single generator, it's not easy to factor-out the steps into subroutines. PEP 380 provides a syntax for having sub-generators which can potentially be used to factor your code into smaller, reusable components.

PEP 380 is about providing better support for nested generators including the scaffolding with try/finally, g.send(), g.next(), g.throw(), and g.close().

In short, PEP 380 lets you nest, and nesting lets you factor your code.