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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
