On Wed, 26 May 2010 22:32:33 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: > > > > Ha, I'm a bit surprised. Isn't it what "futures" already provides? > > (except that for some reason it insists on the "SomeExecutor" naming > > scheme) > > http://www.python.org/dev/peps/pep-3148/#processpoolexecutor > > Not really - a general purpose pool would be a lot more agnostic about > how you give the pooled threads/processes work to do and get the results > back. > > Executors are the kind of thing you would build on top of one though. If > concurrent.pool was added, then the existing processing pools in > multiprocessing and the executors in concurrent.future would be the > first use cases for it. I think I'm a bit ignorant, but how is the Executor abstraction (and its proposed implementations) not generic enough? You have a pool, submit one or several tasks, and can either repeatedly poll for completion or do a blocking wait. (after all, Glyph pointed out that it should be quite easy to wrap the resulting Futures into Deferred objects) cheers Antoine.
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