[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Calvin Spealman]

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