On Tue, May 25, 2010 at 7:54 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On 23/05/10 22:47, Antoine Pitrou wrote: >> >> On Sun, 23 May 2010 08:34:22 -0400 >> Jesse Noller<jnoller at gmail.com> wrote: >>> >>> Brian has already agreed to name spacing it to "concurrent.futures" - >>> this means it will be a small part to a much larger concurrent.* >>> implementation ala Java. >> >> What I would question here is what other things will be part >> of the "concurrent" package, and who will implement them. Are there >> plans for that? (or even tracker issues open?) > > I'm not sure it is called out explicitly in the PEP, but the specific > example that came up in the previous discussions was something like > "concurrent.pool" to hold a thread vs process agnostic worker pool interface > based on the existing Pool interface in multiprocessing (with concrete > implementations for both threading and multiprocessing). > Nick is correct - there's plenty of things in multiprocessing which belong in a more abstract package as they're useful for more things than just multiprocessing. I don't think they need to be called out as part of the PEP though. jesse
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