[Python-Dev] PEP 3148 ready for pronouncement

[Brian Quinlan]

On May 23, 2010, at 7:15 PM, geremy condra wrote:

> On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan <brian at sweetapp.com>  
> wrote:
>
> <snip>
>
>> Finally, why isn't this just a module on PyPI?  It doesn't seem  
>> like there's
>> any particular benefit to making this a stdlib module and going  
>> through the
>> whole PEP process - except maybe to prompt feedback like this :).
>>
>> We've already had this discussion before. Could you explain why  
>> this module
>> should *not* be in the stdlib e.g. does it have significantly less  
>> utility
>> than other modules in stdlib? Is it significantly higher risk? etc?
>
> Inclusion in the stdlib is the exception, not the rule, and every
> exception should be issued for a good reason. I'd like to know
> what that reason is in this case,

This package eliminates the need to construct the boilerplate present  
in many Python applications i.e. a thread or process pool, a work  
queue and result queue.  It also makes it easy to take an existing  
Python application that executes (e.g. IO operations) in sequence and  
execute them in parallel. It package provides common idioms for two  
existing modules i.e. multiprocessing offers map functionality while  
threading doesn't. Those idioms are well understood and already  
present in Java and C++.

> if only to get a clearer
> understanding of why the PEP was accepted.

It hasn't been accepted.

>> 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.
>
> Guido made exactly the opposite argument during his keynote at PyCon.
> It seemed fairly reasonable at the time- why do you think it doesn't  
> apply
> here?


Could you be a little more specific about Guido's argument at PyCon?

Cheers,
Brian