On Sun, May 23, 2010 at 7:52 AM, Steve Holden <st...@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 - 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. " 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 _______________________________________________ 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
