Itertools wishlists

[Raymond Hettinger]

>itertools.window() with n=2 got rejected.  Almost all proposed uses had better
> >solutions (such as an accumulator variable or fibonacci sequence style logic:
> >a, b = b, a+b).  Writing it in C afforded only small speed advantage over a
> >solution using izip() and tee().

[Christos TZOTZIOY Georgiou]
> Speed or C implementation was not my objection.
 . . .
> Just make it
> readily available.  I volunteer for a patch if we agree on it[1].

No thanks.  A patch was developed, discussed, and rejected long ago. The main
reason was that existing approaches were often better (at least in the context
of the use cases that we reviewed).  Performance was mentioned because that is
sometimes used to justify a new tool.  In this case, that justification was not
strong.


> None of the
>
itertools.(queue|roundrobin|accumulate|multi_gen|remove_value|eq|consume|ilines)
> that you reference exists as a recipe in the docs.

FWIW, the recipe for roundrobin is at:
http://docs.python.org/lib/deque-recipes.html .

The only other one worth further discussion is iterequals().  I held-off
publishing that one because the opportunites for error were too great (see the
previous post for details).



> Did I make you believe I cared about the fate of any function judged unworthy
> even for the documentation?

No.  My note was mainly for the benefit of those who had an interest in what
type of ideas had been discussed and the reasoning behind their
inclusion/exclusion.  It needed to be documented somewhere and the newsgroup
discussion on a couple of proposals provided an opportunity to put those notes
on record.



> I'm just whining that putting recipes in the docs as an 'extended
> toolset' instead of in a module is a joking compromise...

Not really.  The recipes have several uses and none of them are compromises.

Firstly, they serve as a proving ground which helps inform further development.
As a recipe, they can be readily altered, improved, or removed without breaking
anything.  However, once I include them as part of the module, the API gets
frozen, as do any accidents of implementation.  Once released, the process of
making repairs or alterations becomes slow and painful.  Over time, some of the
recipes will disappear. some will evolve, and some will work their way into a
module (witness any() and all() as recent examples).

By way of comparision, consider the evolution of set()/frozenset() which went
through stages as recipes, as a PEP, then as Python module, and finally as C
coded built-ins.  That multi-stage process was deliberate and resulted in the
final version being excellent.  Similarly, many new decorators are going to
start their lives as wiki entries or recipes.  Ultimately, some will make it
into the standard library.  It would be a mistake to make that transition too
quickly.

The other purpose of the itertool recipes is to serve as a teaching tool showing
how to combine the tools and how to integrate them with other Python code.  IMO,
most of the recipes are more useful in this capacity than as immediate solutions
to particular problems.



Raymond Hettinger