[Python-Dev] PEP 3148 ready for pronouncement (original) (raw)

Jesse Noller jnoller at gmail.com
Sun May 23 14:34:22 CEST 2010

On Sun, May 23, 2010 at 7:52 AM, Steve Holden <steve at holdenweb.com> wrote: ...snip...

Issues like the ones I'm bringing up could be fixed pretty straightforwardly if it were just a matter of filing a bug on a small package, but fixing a stdlib module is a major undertaking. True but I don't think that is a convincing argument. A subset of the functionality provided by this module is already available in Java and C++ and (at least in Java) it is used extensively and without too much trouble. If there are implementation bugs then we can fix them just like we would with any other module. I don't see the availability of this functionality in those languages as any kind of reason why this needs to go into the stdlib now. Is there some desperate rush to get it in? If it were used extensively from PyPi that would be a recommendation ...

Not picking Steve's particular comments out - but Brian cites the previous discussions in the PEP itself:

http://www.python.org/dev/peps/pep-3148/

All of you questioning "Why should this be in the standard library" should go read those old threads, where that question was answered numerous times. Now I suddenly regret leaving the floodgates open, as we're rapidly rehashing discussions from months ago.

For this same mailing list only a few months ago (brian, I think this link should be added to the PEP, I didn't see it): http://mail.python.org/pipermail/python-dev/2010-March/098169.html

Specifically: http://mail.python.org/pipermail/python-dev/2010-March/098173.html

Quote:

"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

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. "

Brian has already agreed to name spacing it to "concurrent.futures" - this means it will be a small part to a much larger concurrent.* implementation ala Java.

So, in short - given we've already hashed the reasoning out.

jesse

More information about the Python-Dev mailing list