[stdlib-sig] futures - a new package for asynchronous execution

[Antoine Pitrou]

> It feels hacky. Getting the result doesn't feel so special that it  
> deserves to be a call rather than a simple getter.

Well, it is special since the whole point of a future is to get that
result. Like the whole point of a weakref is to get the underlying
object.
Of course this is pretty much bikeshedding...

> It would be great if other people tested the API. I'm not sure what  
> you mean by "mature" though.

What I mean is that it would be nice if it got reviewed, tested and
criticized by actual users. I have not looked at the implementation
though.

> No there isn't. That's a good point though. I wonder if futures will  
> tend to long-lived after there results are available?

It's hard to tell without anyone actually using them, but for advanced
uses I suspect that futures may become more or less long-lived objects
(like Deferreds are :-)).
In a Web spider example, you could have a bunch of futures representing
pending or completed HTTP fetches, and a worker thread processing the
results on the fly when each of those futures gets ready. If the
processing is non-trivial (or if it involves say a busy database) the
worker thread could get quite a bit behind the completion of HTTP
requests.

Twisted has a whole machinery for that in its specialized "Failure"
class, so as to keep the traceback information in string representation
and at the same time relinquish all references to the frames involved in
the traceback. I'm not sure we need the same degree of sophistication
but we should keep in mind that it's a potential problem.

(actually, perhaps this would deserve built-in support in the
interpreter)

> > The use of "with" here still is counter-intuitive, because it does
> not
> > clean up resources immediately as it would seem to do. "with" is  
> > always
> > synchronous in other situations.
> 
> Maybe waiting until all pending futures are done executing would be  
> better.

I think it would be better indeed. At least it would be more in line
with the other uses of context managers.

Regards

Antoine.