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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4