[Python-Dev] PEP 3148 ready for pronouncement

[Brian Quinlan]

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