On Wed, 26 May 2010 22:32:33 +1000 Nick Coghlan <ncogh...@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. _______________________________________________ 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
