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

Andrew Barnert abarnert at yahoo.com
Thu Aug 8 18:50:08 CEST 2013


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?



More information about the Python-ideas mailing list