[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
--
http://mail.python.org/mailman/listinfo/python-list
