[Python-Dev] [PEP 3148] futures - execute computations asynchronously (original) (raw)

Dj Gilcrease digitalxero at gmail.com
Mon Mar 8 20:04:39 CET 2010

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.

More information about the Python-Dev mailing list