On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan <ncogh...@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. _______________________________________________ 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
