[Python-Dev] PEP 3148 ready for pronouncement

[Jesse Noller]

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.