Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
IMO, George Sakkis's original version is better than the TJR's proposed
revision which has three separate adjustments by one and adds to extraneous
functions which aren't central to the example. Dubslow's alternative at least
avoids the three offsets by one; however, it has the disadvantage that meaning
of the loop induction variable is somewhat indirect and creates its own source
of confusion.
I agree that some algorithmic comment should be added, probably just for the
last line.
Let's not add any of the listed alternative names to the comments. Each one is
either confusing or wrong. The word "merge" already has an established,
different meaning as in "sort/merge". For example, heapq.merge('ABC', 'D',
'EF') gives ['A', 'B', 'C', 'D', 'E', 'F']. The word "alternate" tends to mean
"toggle back-and-forth" in common usage. The term "zip_flat" has no meaning to
me, it has no hits on Google, and the closest match is a recipe on
StackOverflow that does something different. And "interleave" is not
suggestive of looping back over the iterables until each is exhausted. Also,
we may yet use interleave() to mean something else.
In contrast, "round robin" has a well established meaning that matches what
this recipe does. Until now, not a single reader has ever claimed to not know
what it means. https://en.wikipedia.org/wiki/Round-robin_scheduling
FWIW, the recipe has several benefit. 1) Give a way to implement round robin
iteration without re-inventing the wheel, 2) Demonstrate ways to use cycle()
and islice(). 3) Demonstrate useful optimization technique of factoring the
try/except out of the for-loop, 4) Demonstrate the useful optimization
technique of calling bound methods, and 5) Be concise (I've left longer or more
complex recipes for the ASPN cookbook or StackOverflow).
Ideally, I would prefer to not add two extra builtin lookups (the recipe is
sometime used on short inputs which would be affected by the extra overhead).
Also, I prefer the visual weight to be on the central message of tight inner
loops that exploit itertools rather than having the visual weight shift to the
for-loop which is the least important part.
Can you a suggest a concise single line comment that would make the last line
clearer about what it is doing? Also, I'm open to changing the name of the
"pending" variable but think "current_len" and "reduced_len" are not
improvements.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32099>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
