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
_______________________________________________
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