Back in May, Guido assigned me “single-use” BDFL powers when deciding on the state of PEP 3148. I had been working on and off with Brian since his original proposal to the stdlib-sig mailing list.
Tonight, I “officially accepted” the PEP Brian’s put a lot of work into. You can check out the PEP itself, or play with the code over here. The credit goes to Brian, and the small army of people who gave him feedback including Jeffery Yasskin who spent a fair amount of time iterating and expounding on things.
Below, is a snippet from one of my original emails to python-dev on my reasoning for supporting the library, and also adding in the “concurrent” namespace.
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.
With that done, I am back to being only the benevolent dictator of my lawn, which is mostly dead.
Also, for added fun – check out the PyCon AU talk Brian did!