[Python-Dev] PEP 3148 ready for pronouncement

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:

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