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?
> I'd also consider a simple thread pool and an actual executor different
> things. I'm fine with the longer names, but if I was going to drop a
> word from the names, it would actually be "Pool" (i.e. ThreadExecutor,
> ProcessExecutor).
To me, ThreadPool looks a lot more obvious than ThreadExecutor
("obvious" in that I can easily find it again, and I don't need to
read some documentation to know what it is).
Regards
Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4