On Jul 9, 2012 6:17 AM, "alex23" <wuwei23@gmail.com> wrote:
>
> On Jul 7, 4:14 am, Jürgen A. Erhard <jae+pyt...@jaerhard.com> wrote:
> > So... I consider it very strange and annoying that there's this code.
> > Ready to use.  But you have to copy-and-paste it into your code
> > *somewhere* instead of easily importing it.
>
> I find it strange and annoying when people expect the standard library
> to contain _everything_. What you gain in the convenience of readily
> imported code imposes a cost on the ongoing maintenance and support of
> the standard lib. Are you volunteering to write the PEP for its
> inclusion, provide the implementation and support it until the end of
> time?

While I agree that these recipes are not suitable for inclusion in stdlib (for reasons made elsewhere), I don't agree with your (somewhat aggressive) reasoning. The implementation has already been provided, and is being maintained in the form of documentation. Simply copying the recipes into a module is hardly an onerous task. And fairly often people mailing to this list *are* volunteering to write a PEP, provide an implementation, etc.

>
> > As to the "it makes using Python harder to learn", I beg to
> > differ: an addition to the *language* (like, say, metaclasses) *can*
> > make it more complicated.  But additions to the stdlib?  What about
> > "batteries included"?  Not a motto anymore (I heard rumors, so maybe
> > that's the case)
>
> Every single function added to the library makes the library broader
> and thus more difficult to retain in memory.
>
> It _is_ possible to present a case without snide allusions based on
> hearsay: http://www.python.org/about/
>
> > Putting these in some official(!) iterutils (or name it what you want)
> > package would be a solution for so many people.  Yes, not everyone
> > needs grouper's current functionality.  But for the many who do, it'd
> > be there already.
>
> So in the extremely likely outcome that a piece of functionality has
> multiple implementations with different interpretations of edge cases,
> who gets to decide which one is "more standard" than the other? If
> such a decision has to be made, then it's not really "standard".
>
> > And someone thought those recipes are useful,
> > didn't you?  So why not make them more easily available?
>
> Because not everything needs to be in the standard library.
>
> Because searching somewhere like Activestate's cookbook and copying
> the implementations you find useful really isn't an onerous task.
>
> Because if *you* feel there's an obvious lack in the stdlib then roll
> your own package that covers it and put it up on PyPI. If it becomes
> insanely popular, then you have a lot more leverage for insisting that
> something would be beneficial to be included other than gut feeling &
> convenience.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> http://mail.python.org/mailman/listinfo/python-ideas