On Wed, May 26, 2010 at 3:57 AM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Having read through the PEP again, here are my thoughts. > > * I'm bothered by the term "future". To my mind, it's > too long on cleverness and too short on explanativeness. > > I think that the standard library is no place for > cuteness of naming. The name of a stdlib module should > reflect its functionality in some straightforward and > obvious way. If I were looking for a thread pool or > process pool implementation, the word "future" is not > something that would spring readily to mind.
Please go re-read the older threads on this. For example, http://mail.python.org/pipermail/python-dev/2010-March/098279.html. > * 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. +0 > * 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. Again, please re-read the older thread (which you participated in). For example, http://mail.python.org/pipermail/python-dev/2010-March/098200.html. Jeffrey _______________________________________________ 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
