[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[P.J. Eby]

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.