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 <jnol...@gmail.com> wrote: > On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman <ironfro...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
