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

geremy condra debatem1 at gmail.com
Sun May 23 11:15:12 CEST 2010

On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan <brian at sweetapp.com> wrote:

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, if only to get a clearer understanding of why the PEP was 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?

Geremy Condra

More information about the Python-Dev mailing list