[Python-Dev] PEP 3148 ready for pronouncement
Antoine Pitrou
solipsis at pitrou.net
Wed May 26 14:50:33 CEST 2010
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.
More information about the Python-Dev
mailing list