[Python-ideas] Mont-E technical details, PEP 380, Monocle

[Laurens Van Houtven]

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