On "zip":

I'm sure most readers of this thread are aware that the snake-language
introduced about two years ago a "zip" function very much like the method
being proposed here -- same name and everything. Although I'm a Ruby fan and
write lots of Ruby, I do a lot of programming in Python since my company's
product has lots of Python code. And I can't actually remember ever using
"zip". Parallel iteration is an occasional need (in my world), but not
exactly a *frequent* need. When parallel iteration is needed, other
techniques like each_with_index work just fine. This is a YAGNI (the acronym
I just learned :-) warning.

One of the reasons I don't like using Python's "zip" is that it actually
zips up all of the input sequences into a physical result sequence (similar
to their "range" function which is semantically like Ruby's "m...n" but
returns a physical sequence) -- it's always bothered me to have to create a
possibly large sequence to do that operation when it isn't necessary.
Hopefully, if "zip" becomes part of Ruby, the implementation could be as an
iterator which never builds a physical version of the zipped sequence. But
that is an implementation challenge if the input sequence are general
instances of Enumerable, since the input sequences cannot be efficiently
iterated in parallel. (If the input Enumerables were limited to those which
are numerically indexed, such as Arrays, implementation would be easy -- but
it would be unfortunate to have to make that restriction.)

Anyway, my personal feeling about "zip" is that I would likely use it only
if it could efficiently iterate the zipped elements of the input sequences
without creating a full physical output sequence. Otherwise, I don't think
it's especially useful.

By the way, I just scanned the Python library code in the most recent
distribution and, outside of test modules, there are only two occurrences of
"zip"!


Bob