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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
