RetroSearch Browse

Thu May 27 18:05:14 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-May/100417.html

On 27/05/10 10:29, Antoine Pitrou wrote:
> On Thu, 27 May 2010 10:19:50 +1000
> Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>
>> futures.ThreadPoolExecutor would likely be refactored to inherit from
>> the mooted pool.ThreadPool.
>
> There still doesn't seem to be reason to have two different thread pool
> APIs, though. Shouldn't there be one obvious way to do it?

Executors and thread pools are not the same thing.

I might create a thread pool for *anything*. An executor will always 
have a specific execution model associated with it (whether it be called 
futures, as in this case, or runnables or something else).

This confusion is making me think that dropping the "Pool" from the 
names might even be beneficial (since, to my mind, it currently 
emphasises a largely irrelevant implementation detail).

Cheers,
Nick.

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-May/100417.html below:

[Python-Dev] PEP 3148 ready for pronouncement