[Python-Dev] PEP 3148 ready for pronouncement

[Nick Coghlan]

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------