On Sun, Oct 14, 2012 at 2:17 PM, Guido van Rossum <guido@python.org> wrote:

On Sun, Oct 14, 2012 at 10:55 AM, Jasper St. Pierre <jstpierre@mecheye.net> wrote:

...

(Sorry if this is in the wrong place, I'm joining the conversation and I'm not sure where mailman will put it)

...

Alternatively, yielding a future (or whatever ones calls the objects returned by *_async()) could register *and* wait for the result. To register without waiting one would yield a wrapper for the future. So one could write

What would registering a Future do? As far as I understood it, the plan here is that a Future was just a marker for an outstanding request:

def callback(result): print "The result was", result

def say_hello(name): f = Future() f.resolve("Hello, %s!") return f

f = say_hello("Jeff") f.add_callback(callback)

The outstanding request doesn't have to care about socket connections; it's just a way to pass around a result that hasn't arrived yet. This is pretty much the same as Deferreds/Promises, with a different name. There's no reactor here to register here, because there doesn't need to be one.

The Future class itself probably shouldn't interface with the event loop. But an operation that creates and returns a Future certainly can.

Of course, but that wouldn't be done at the Future level, but at the fetch_async level. I just want to make sure that we're clear that the Future itself isn't being registered with any event loop or reactor.

-- --Guido van Rossum (python.org/~guido)

-- Jasper

On Sun, Oct 14, 2012 at 2:17 PM, Guido van Rossum <guido@python.org> wrote:

On Sun, Oct 14, 2012 at 10:55 AM, Jasper St. Pierre <jstpierre@mecheye.net> wrote:

...

(Sorry if this is in the wrong place, I'm joining the conversation and I'm not sure where mailman will put it)

...

Alternatively, yielding a future (or whatever ones calls the objects returned by *_async()) could register *and* wait for the result. To register without waiting one would yield a wrapper for the future. So one could write

What would registering a Future do? As far as I understood it, the plan here is that a Future was just a marker for an outstanding request:

def callback(result): print "The result was", result

def say_hello(name): f = Future() f.resolve("Hello, %s!") return f

f = say_hello("Jeff") f.add_callback(callback)

The outstanding request doesn't have to care about socket connections; it's just a way to pass around a result that hasn't arrived yet. This is pretty much the same as Deferreds/Promises, with a different name. There's no reactor here to register here, because there doesn't need to be one.

The Future class itself probably shouldn't interface with the event loop. But an operation that creates and returns a Future certainly can.

Of course, but that wouldn't be done at the Future level, but at the fetch_async level. I just want to make sure that we're clear that the Future itself isn't being registered with any event loop or reactor.

-- --Guido van Rossum (python.org/~guido)

-- Jasper