[Python-Dev] [PEP 3148] futures - execute computations asynchronously
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