[Python-Dev] Re: Itertools

[Terry Reedy]

>     python/nondist/sandbox/itertools
>
> The docs and examples are a good place to start.
------------------

OK.  Reading the raw .tex file...

dropwhile and takewhile: param 'invert' in the def line is not in the
heading or description and is not used in the body.  I presume this is
a holdover that should have been deleted?

For dropwhile(), I would replace (for didactic purposes, C code does
not matter)

if not predicate(x):
    yield x
    break

which seems backwards to me, with

if predicate(x): continue #ie, drop while x is true
yield x
break
-----------

ifilter: the purpose of 'invert' is to avoid having to wrap a
preexisting predicate p with lambda x: not p(x).  If this is useful
and a good idea here, it would be equally so for filter.  I am in
favor of keeping the interface and meaning of such pairs the same as
much as possible.
-------------

imap: "Like map() except that it returns an iterator instead of a list
"  Since all itertool functions return an iterator (instead of a
finite sequence) this does not need to be specially repeated here.
Doing so tends to give the impression that there is something special
in this regard about imap, which  I don't think there is.

"and that it stops when the shortest iterable is exhausted
instead of filling in \code{None} for shorter iterables"
---------
times:

There is a puzzling irony here.  map(), which tries to produce a
finite list, will croak trying to produce an infinite list if on of
its inputs is.  But it has to try, even if at least one input is
finite, for backwards compatibility. But you propose that imap(),
which very well could continue indefinitely (and will if all inputs
do), act differently.  Is the reason ease of use and efficiency (which
I can see in the Python version) or something else?

Please add a line of explanation.  I am 99% certain this question will
come up on c.l.p and it would be nice to have something to quote or
refer people to.
----------

Terry J. Reedy