On 26 May 2010, at 22:42, Nick Coghlan wrote: > On 26/05/10 20:57, Greg Ewing wrote: >> Having read through the PEP again, here are my thoughts. >> * It seems unnecessarily verbose to tack "Executor" >> onto the end of every Executor subclass. They could >> simply be called ThreadPool and ProcessPool without >> losing anything. > > We would lose the ability to add general purpose thread and process > pools under the obvious names later. > >> * I don't see a strong reason to put this module >> inside a newly-created namespace. If there were a >> namespace called "concurrent", I would expect to find >> other existing concurrency-related modules there as >> well, such as threading and multiprocessing. But we >> can't move them there without breaking existing code. >> >> (More generally, I'm inclined to think that introducing >> a namespace package for a category of modules having >> existing members in the stdlib is an anti-pattern, >> unless it's done during the kind of namespace refactoring >> that we won't get another chance to perform until Py4k.) > > _thread, threading, Queue and multiprocessing do likely belong here, > but moving them isn't likely to be worth the pain. Does it help to > know that at least Jesse and I (and probably others) would like to > see concurrent.pool added eventually with robust general purpose > ThreadPool and ProcessPool implementations? > > The specific reason the new package namespace was added was to help > avoid confusion with stock market futures without using an unduly > cumbersome module name, but I don't know how well the PEP explains > that. It doesn't at all. Are these plans formalized anywhere that I can link to? Cheers, Brian
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