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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4