[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