[Python-3000] Futures in Python 3000

Michael Chermside mcherm at mcherm.com
Fri Apr 21 00:12:55 CEST 2006


Guido writes
> Let me just add that Andy is wasting his time. Python 3000 won't have
> continuations.

Andy writes:
> Huh?  Futures are very different from continuations.  I still have a
> hard time understanding continuations (and am no fan of them), but
> futures seem to be a rather simple abstraction to comprehend.

Andy:

You are right... futures are not continuations, and there is no reason
for Guido to fear them. However, here me out on the idea of futures in
Python:

Python HAS futures. They are implemented using the Deferred object in
Twisted. Anyone writing Python code in a callback style uses the Twisted
library, it's the standard tool for that job in Python (and it's quite
good at what it does). Unfortunately, it does require you to turn your
code "inside out", and you probably want to avoid that.

Some languages (like alice) manage to implement futures in a way that
allows code to be written "right-side out". But this requires the entire
language being built around such a concept. I have heard Bruce Eckel put
forth the idea of supporting "Active Objects" which would be a related
concept with similar benefits, but even then he never suggested
supporting it for all objects.

I doubt anyone would seriously consider totally redesigning the core of
Python to allow futures. So the best hope for futures would be if they can
be implemented without core modifications. I can imagine, for example, an
object called 'Future', that was used like this:

   widget = Future( long_running_get_widget_func, arg1, arg2 )
   x = other_slow_function(argA, argB)
   widget.set_color( x )


The Future object would launch the long-running function in a separate
thread then return a proxy object. When attributes of the proxy object
were accessed, they would block if the function was still running, and
otherwise forward to the result of the function. There are design points
to be addressed about whether there would be explicit joins and so forth.

The good news is that this is completely possible in Python today! So
there is no need to bring this up on the Python 3000 discussion group.
Instead, go out there and write the "Future" library, then make it
available on cheeseshop.python.org. Promote your library on
comp.lang.python. Once your library is popular enough, propose adding it
to the standard library. And none of this needs to wait for Py3K... it
could all happen by 2.6!

Seriously... futures are a GREAT tool. The above is a way to get it moving
in Python without needing support from the core language team... and that
means it gets done faster!

-- Michael Chermside



More information about the Python-3000 mailing list