> 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. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
