[Python-ideas] Add 'interleave' function to itertools?

[David Mertz]

I agree that most of the recipes for clever combinations of itertools
functions--at least those that have intuitive and obvious names--should
simply be put into the module itself (and per Andrew, they can nonetheless
by documented as recipes).

Even if these implementations can be done as one-liners that stitch
together a few existing functions, that's not really any reason not to
include them in the namespace.  There are too many ways to do those
one-liners slightly wrong, and no need to add to the cognitive burden of
someone who just wants to, e.g. interleave.

On Thu, Aug 8, 2013 at 9:50 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Aug 8, 2013, at 6:47, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> > Le Thu, 8 Aug 2013 15:28:15 +0200,
> > Masklinn <masklinn at masklinn.net> a écrit :
> >> On 2013-08-08, at 06:01 , Stefan Behnel wrote:
> >>
> >>> MRAB, 07.08.2013 22:12:
> >>>> And are these functions worthy of inclusion in itertools? :-)
> >>>
> >>> The fact that they are a short construction of the existing tools
> >>> indicates that they are better suited for the recipes section than
> >>> the itertools functions section of the module docs. There is
> >>> already a roundrobin() recipe.
> >>
> >> I'm really not fond at all of the "recipes" section, at least under
> >> its current incarnation: it's nice to have examples of composing
> >> itertools functions to build more specialized or higher-level tools,
> >> but recipes functions should be available in itertools or a
> >> submodule: the work has been done already, it's wasteful and annoying
> >> to have to copy/paste these functions to some arbitrary location
> >> every time they are needed, that's what libraries are for.
> >
> > I agree with this, plus there's always the risk of making a mistake
> > when pasting them, and unit tests are not included.
>
> And you have to either "from itertools import *" or edit the recipes after
> pasting.
>
> I agree that at least some of them belong in the actual module. Sure, a
> few are so trivial that the first time, you copy/paste/edit you'll be able
> to write it yourself from thereafter. And others are rarely useful. But
> grouper, which is the one-word answer to dozens of StackOverflow questions
> per year, or unique_everseen, which people regularly put effort into trying
> every which way to optimize before realizing the recipe already did it,
> etc., those should be in the module.
>
> Of course having the source in the docs does serve a teaching purpose
> (although with no explanations, it's not always as much of a purpose as
> you'd like--I can't think of anyone who's ever seen grouper who couldn't
> have written it himself but who can understand it without a long
> explanation). But that's not a problem. There's no reason the source to
> selected functions can't be in the docs even though it's also in the module.
>
> While we could debate about which ones are useful, and which are either
> too trivial or too rare, how much harm is there in just adding all of them?
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130808/780982da/attachment.html>