Itertools wishlists

[Christos TZOTZIOY Georgiou]

On Sun, 13 Mar 2005 06:52:40 GMT, rumours say that "Raymond Hettinger"
<vze4rx4y at verizon.net> might have written:

[snip of lots of stuff]

>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().

Speed or C implementation was not my objection.  I don't care if C itertools
gets renamed to _itertools and some Python itertools imports _itertools first
thing a la heapq, and then the most probably useful doc recipes get defined in
Python; in fact, I would like that.  Do you think that window is rarely used?
You didn't say that in your post, you just argued against implementing it in C.
I agree.  Don't implement it in C.  Implement it as in the recipe.  Just make it
readily available.  I volunteer for a patch if we agree on it[1].

For example, if speed is our main concern, why is there PEP 309 for partial
function application as a class?  The tools are already there, and
new.instancemethod is our friend.  In the case of binding only the first
argument, which is the most common, calling the resulting object is 2% faster
than calling the function itself (at least on my laptop).  Of course, PEP 309 is
not about speed; it's about availability of /correct/ and /useful/
functionality.  Kind of like recipes in the itertools documentation.

>'nuff said, mister whatever happened to batteries included ;-)

Cool extensive summarising reply --however, how relevant is it?  None of the
itertools.(queue|roundrobin|accumulate|multi_gen|remove_value|eq|consume|ilines)
that you reference exists as a recipe in the docs.

Did I make you believe I cared about the fate of any function judged unworthy
even for the documentation?  Because, if it is my fault, let me correct that: I
am talking about the recipes in the documentation (those found worthy enough to
be included in the docs, but not found worthy enough to be included in the lib),
and specifically for window and flatten: why aren't they considered as
batteries?  About flatten, you say things are still warm.  About window, you say
it's not really efficient, use izip and tee, or use a deque for n>2.  Ok.  I
never spoke about speed.  I spoke about tool availability.

IIRC you were cooled down in Python-Dev from adding more functions into
itertools; it was kind of a surprise for me now to see /you/ of all people
defending this choice.  FWIW, I like speed (who doesn't if nothing else is
affected?); I have an unpolished CPython pcode decompiler / compiler that offers
a decorator for function-level optimising and a function that modifies *.py[co]
files replacing patterns like the one you yourself lately worried about [2],
which module I leave as-is partly waiting the AST branch to be finished and
partly because now and then you implement some part of it in the peephole
optimiser.  So no objections about speed, just note that I didn't mention it in
my previous post.

AFAIAC, in my own stdlib-supporting modules what I need is readily available;
possibly I'm just whining that putting recipes in the docs as an 'extended
toolset' instead of in a module is a joking compromise...

>P.S.  It's not an accident that the recipes in the itertools docs are in a form
>that is directly cut and pastable into a working application.

[1] Like I said, I volunteer to copy-paste from the docs into a Python module
for the stdlib.  Thanks for the eye-opening hint!-)

[2] STORE_<sth> x/LOAD_<sth> x into DUP/STORE_<sth> x, local binding of multiple
LOAD_sth x/LOAD_ATTR/LOAD_ATTR where x is an imported module into a LOAD_FAST or
a LOAD_CONST based on whether it's the modifier or the decorator,
LOAD_CONST*/BUILD_LIST into LOAD_CONST a_tuple/UNPACK_SEQUENCE/BUILD_TUPLE,
"a,b,c=d,e,f" reordering and dropping of the tuple building/unpacking (which is
a case already improved in C) etc.
-- 
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...