On Wed, May 26, 2010 at 8:42 AM, Nick Coghlan <ncogh...@gmail.com> 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.
I assume(d) it's sufficient to link to the mailing list threads where we hashed this out already ;) The namespace serves a few purposes: 1 > We put futures where it makes sense - into a concurrent package. Futures are a concurrency construct; therefore it simply makes sense to put them within a sub package rather on the top level. 2 > We carve out a box to move to, and add other concurrent things, such as generic pools, Actor implementations, etc. See java.util.concurrent. Things within multiprocessing that don't start with P and rhyme with "rocess" can go here too. Admittedly, it's mainly my own long-term vision to see python-core grow more concurrency tidbits - although I don't know too many people who would complain about it. jesse _______________________________________________ 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
