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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4