[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Jesse Noller jnoller at gmail.com
Wed May 26 15:17:54 CEST 2010

On Wed, May 26, 2010 at 9:01 AM, Brian Quinlan <brian at sweetapp.com> wrote:

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

Nope; and I don't think we need to worry about it right now.

More information about the Python-Dev mailing list