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. > I thought that the specification would be difficult to follow without > examples to pave the way. Well, for me, what happened was that I saw the examples and thought "WTF is going on here?" Then I read the specification to figure out how the examples worked. It might be better to have a tutorial section preceeding the specification section, containing explanation interspersed with examples. > I think that > idiomatic future use will end up looking similar to my examples. Maybe, but code written for pedagogical purposes needs to meet a particularly high standard of clarity. Remember that the reader isn't yet familiar with the idioms, so idiomatic code isn't necessarily going to be easy for him to follow. >> * Is it possible to have more than one Executor active >> at a time? > > Of course. That's good, but I don't think that the "of course" is at all obvious, considering that things such as GUI event loops generally can't be mixed easily. -- Greg
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