[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Dj Gilcrease]

On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Wouldn't a factory function serve that purpose just as well? Or even
> just "from concurrent.futures import ProcessPoolExecutor as TaskExecutor".
>
> That last form has the virtue that you can retrieve your executor from
> anywhere rather than being limited to the two provided by the
> concurrent.futures model.
>
> I think the string based approach actually unduly constrains the API
> despite superficially appearing to make it more flexible.

mm you are correct, I went with the string approach because I was
experimenting with 3 additional executor types and wanted to be able
to switch between or intermix them them without having to change
imports and didnt feel like writing a register class with a factory
method.

A style I have used in my own code in the past is a Singleton class
with register and create methods, where the register takes a
name(string) and the class and the create method takes the name and
*args, **kwargs and acts as a factory.

Would this style be better or would it be better to just leave it with
the two executor classes? I tend to dislike multiple classes for a
what is essentially a Strategy of a concept and factories are
something I tend to forget about until well after my initial idea has
formed into a proof of concept.