Real-world use cases for map's None fill-in feature?

[Raymond Hettinger]

[Raymond]
> > Both approaches require a certain measure of inventiveness, rely on
> > advanced tricks, and forgo readability to gain the raw speed and
> > conciseness afforded by a clever use of itertools.  They are also a
> > challenge to review, test, modify, read, or explain to others.

[Peter Otten]
> Is this the author of itertools becoming its most articulate opponent? What
> use is this collection of small functions sharing an underlying concept if
> you are not supposed to combine them to your heart's content? You probably
> cannot pull off some of those tricks until you have good working knowledge
> of the iterator protocol, but that is becoming increasingly important to
> understand all Python code.

I'm happy with the module -- it has been well received and is in
widespread use.  The components were designed to be useful both
individually and in combination.

OTOH, I sometimes cringe at code reminiscent of APL:

    it = chain(iterable, repeat('', group_size-1))
    result = izip(*[it]*group_size)

The code is understandable IF you're conversant with all the component
idioms; however, if you're the slightest bit rusty, the meaning of the
code is not obvious.  Too much of the looping logic is implicit (1D
padded input reshaped and truncated to a 2D iterator of tuples); the
style is not purely functional (relying on side-effects from multiple
calls to the same iterator); there are two distinct meanings for the
star operator; and it is unlikely that a most people remember the
precedence rules for whether *[it] expands before the [it]*group_size
repeats.  All in all, it cannot be claimed to be a masterpiece of
clarity.  That being said, if speed was essential, I would use it every
time (as a separate helper function and never as in-line code).

Of course, the main point of the post was that Duncan's use case was
readily solved with existing tools and did not demonstrate a need for
izip_longest().  His original code was almost there -- it just needed
to use chain() instead of list concatenation.

> Regarding the thread's topic, I have no use cases for a map(None, ...)-like
> izip_longest(), but occasionally I would prefer izip() to throw a
> ValueError if its iterable arguments do not have the same "length".

The Standard ML authors agree.  Their library offers both alternatives
(with and without an exception for unequal inputs):

http://www.standardml.org/Basis/list-pair.html#SIG:LIST_PAIR.zipEq:VAL

Thanks for the input,

Raymond