I revert my objections. I still would like to see this in use "in the wild" and I might even use it thusly, myself. On Fri, Mar 5, 2010 at 9:50 AM, Jesse Noller <jnoller at gmail.com> wrote: > On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman <ironfroggy at gmail.com> wrote: >> A young library solving an old problem in a way that conflicts with >> many of the other implementations available for years and with zero >> apparent users in the wild is not an appropriate candidate for a PEP. >> > > Baloney. A young library providing some syntactic sugar which uses > primitives in the standard library to implement a common pattern is > fine for a PEP. We've hashed this out pretty heavily on the stdlib-sig > list prior to bringing it here. By the same argument, we should shunt > all of the recent unittest changes and improvements into space, since > golly, other people did it, why should we. > > This is something relatively simple, which I would gladly add in an > instant to the multiprocessing package - but Brian's one-upped me in > that regard and is providing something which works with both threads > and processes handily. Take a look at multiprocessing.Pool for example > - all that is some sugar on top of the primitives, but it's good > sugar, and is used by a fair number of people. > > Let me also state - "my" vision of where futures would live would be > in a concurrent package - for example: > > from concurrent import futures > > The reason *why* is that I would like to also move the abstractions I > have in multiprocessing *out* of that module, make them work with both > threads and processes (if it makes sense) and reduce the > multiprocessing module to the base primitive Process object. A > concurrent package which implements common patterns built on top of > the primitives we support is an objectively Good Thing. > > For example, how many of us have sat down and implemented a thread > pool on top of threading, I would hazard to say that most of us who > use threading have done this, and probably more than once. It stands > to reason that this is a common enough pattern to include in the > standard library. > > In any case; consider me a strong +1 to adding it. > > jesse > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
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