On 27/05/10 09:36, Greg Ewing wrote: > Brian Quinlan wrote: > >> I think that Jesse was planning to add some functionality to this >> namespace. > > Even if that happens, the existing threading and multiprocessing > modules would remain outside of it. > >> You could have general thread pools that aren't related to executors > > Yes, but it should be fairly obvious that the ones defined > in the futures module have to do with futures. Namespaces are > only a honking great idea if you actually let them do the job > they're designed for. futures.ThreadPoolExecutor would likely be refactored to inherit from the mooted pool.ThreadPool. I'd like to leave that option open, and having two classes with the same name from different modules in a single inheritance tree is one of the places where module namespacing still isn't quite as tidy as we might wish. 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). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
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