Hi! The people who attended EuroPython might remember my lightning talk about Mont-E. I wanted to go into more technical detail, but as I said in the talk it was very early days, and I was unable to get a reliable enough internet connection near the talk to really know what was done and what wasn't in detail (and I didn't want to lie about features that did and did not work). For those who haven't: it's a set of patches on top of Py3k that tries to introduce some of the ideas of E (a programming language) into Python. I just read Guido's python-dev post and I was listening in on the discussion after Raymond's talk, and I agree with pretty much everything what was said in both cases. The most important part is PEP 380 expressing a great idea; which is pretty much done and ready for real use, I think the best proof of that is that people have already tried to solve it and the solutions people come up with are quite similar (except that one is specifically tuned towards subgenerators and the other isn't): Twisted's returnValue and Mont-E's return-from-a-generator. The latter looks like this: def port_scan(hostname): ip = defer gethostbyname(hostname) ports = set() for port in range(65536): if (defer is_port_connectable(ip, port)): ports.add(port) return ports (Except that uses E-style promises + resolvers, instead of Twisted and Monocle style deferreds.) I'm not suggesting Mont-E's syntax makes it in favor of anything else, like I mentioned in the talk we really just wanted an excuse to mess with the grammar (the official excuse is "we wanted to see what we could do given the power to do anything including mangling half the stdlib and grammar" ;-)). port_scan(spam) would return a promise, not a generator. Like @inlineCallbacks, the goal of yield/defer is to basically say "oh, okay, you can do other stuff now, just call me back as soon as this thing is done". The value of the promise is the returned value. I think in its core this is analogous to PEP380, except that this takes it a step further and applies it to callbacks/deferreds (well, callbacks/promises+resolvers, technically, but I say deferreds because it's close enough and people are familiar with them). I think stuff like Monocle is a great idea because it introduces portability for async code. I like Twisted and I will continue writing Twisted stuff regardless, but I would much rather write asyncOAuth which everyone can use than txOAuth which only Twisted users could use. I think Monocle shows how these two things are related. How do people feel about a portable-async-code story for the stdlib? Mont-E tries to do this in ways that will be... ahum... let's say "hard" to get into the stdlib: by introducing promises, resolvers, event loops, interfaces... I also agree that CSP is a good model; I prefer actor for most of the stuff I end up writing; but there are definitely cases (for my stuff this tends to be about numerical computation) where CSP rocks. But the stdlib already has multiprocessing, maybe it's time we started looking at other stuff :-) thanks in advance for your input Laurens