[Python-Dev] PEP 3148 ready for pronouncement

[Jesse Noller]

On Wed, May 26, 2010 at 8:42 AM, Nick Coghlan <ncoghlan at gmail.com> 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.


I assume(d) it's sufficient to link to the mailing list threads where
we hashed this out already ;)

The namespace serves a few purposes:

1 > We put futures where it makes sense - into a concurrent package.
Futures are a concurrency construct; therefore it simply makes sense
to put them within a sub package rather on the top level.

2 > We carve out a box to move to, and add other concurrent things,
such as generic pools, Actor implementations, etc. See
java.util.concurrent. Things within multiprocessing that don't start
with P and rhyme with "rocess" can go here too.

Admittedly, it's mainly my own long-term vision to see python-core
grow more concurrency tidbits - although I don't know too many people
who would complain about it.

jesse