[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)

P.J. Eby pje at telecommunity.com
Sun Mar 7 16:48:09 CET 2010

At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:

P.J. Eby wrote: > (Personally, I think it would be better to just drop the ambitious title > and scope, and go for the "nice task queue" scope. I imagine, too, that > in that case Jean-Paul wouldn't need to worry about it being raised as a > future objection to Deferreds or some such getting into the stdlib.)

This may be a terminology thing - to me futures are just a nice way to handle farming tasks out to worker threads or processes. You seem to see them as something more comprehensive than that.

Actual futures are, yes. Specifically, futures are a mechanism for asynchronous computation, whereas the PEP seems to be all about synchronously managing parallel tasks. That's a huge difference.

Technically, the things in the PEP (and by extension, Java's futures) match the letter of the definition of a future, but not (IMO) the spirit. There's no clean way to compose them, and at base they're more about parallelism than asynchrony.

I agree the PEP should just target what the current implementation provides and put whatever scope limitations are needed in the preamble text to make that clear.

Yep. I'm just saying "parallel task queueing" is a much better description of what the implementation is/does, and would suggest renaming Future -> Task and Executor -> WorkerPool or some such. These names would be much clearer to people who've never heard of futures, as well as more appropriate to the actual scope of what this does.

More information about the Python-Dev mailing list