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 _______________________________________________ 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
