Zip with a list comprehension

[Matt Gerrans]

This is probably so easy that I'll be embarrassed by the answer. While
enhancing and refactoring some old code, I was just changing some map()s to
list comprehensions, but I couldn't see any easy way to change a zip() to a
list comprehension. Should I just let those sleeping dogs lie? (list
comprehensions seem more readable than map(), but if the list comprehension
that does the equivalent of zip() is less expressive than zip(), I'll stick
with zip()).

[Steven Bethard]

Matt Gerrans wrote:

This is probably so easy that I'll be embarrassed by the answer. While
enhancing and refactoring some old code, I was just changing some map()s to
list comprehensions, but I couldn't see any easy way to change a zip() to a
list comprehension. Should I just let those sleeping dogs lie? (list
comprehensions seem more readable than map(), but if the list comprehension
that does the equivalent of zip() is less expressive than zip(), I'll stick
with zip()).

Hmmm... I couldn't do any better than:

seqs = [(1, 2, 3), (4, 5, 6, 7)]
zip(*seqs) [(1, 4), (2, 5), (3, 6)] [tuple(seq[i] for seq in seqs)

.... for i in range(min(len(seq) for seq in seqs))]
[(1, 4), (2, 5), (3, 6)]

I think I'll stick with zip. ;)

I too have been trying to make my code more conformant with Python 3000
recommendations (e.g. removing maps in favor of LCs or GEs, replacing
lambdas with named functions, etc.) but I've left zip pretty much alone.

Steve

[Carl Banks]

Matt Gerrans wrote:

This is probably so easy that I'll be embarrassed by the answer. While enhancing and refactoring some old code, I was just changing some map()s to list comprehensions, but I couldn't see any easy way to change a zip() to a list comprehension. Should I just let those sleeping dogs lie? (list comprehensions seem more readable than map(), but if the list comprehension that does the equivalent of zip() is less expressive than zip(), I'll stick with zip()).

I don't recall seeing zip on the list of things that were considered
bad for Python 3K, probably because it's not functional programming (a
la map, reduce, and filter) but rather just list manipulation.

I can't think of a good way to replace zip with a list comp, and I
doubt there is such a way. Think about it: a list comp is semantically
equivalent to a certain for loop (or loops, perhaps with some if-blocks
in there as well). A list comp can do only what a for loop can do,
nothing more.

Well, zip was created to address a deficiency in for-looping, namely
that it was unwieldy to loop through two lists side-by-side. I suspect
that, if there were a simple way to accomplish what zip does in a list
comp, there would have also been an easy way to do it with for loops,
and therefore zip would not have had any reason to exist.

So, unless the BDFL waves his magic wand and adds some new syntax for
for loops (unlikely), I think you can operate under the assumption that
zip will be Python 3000 Certified (tm).

Having said that, you might want to consider using itertools.izip
instead. It works just like zip, but returns an iterator instead of a
list. Good for those length-ten-million lists you wanted to iterate
side-by-side.
--
CARL BANKS

[Raymond Hettinger]

> This is probably so easy that I'll be embarrassed by the answer. While

enhancing and refactoring some old code, I was just changing some map()s to
list comprehensions, but I couldn't see any easy way to change a zip() to a
list comprehension. Should I just let those sleeping dogs lie? (list
comprehensions seem more readable than map(), but if the list comprehension
that does the equivalent of zip() is less expressive than zip(), I'll stick
with zip()).

Leave in zip(), enumerate(), and reversed().
They are meant to be used with listcomps and genexps.

If you want to go the extra distance, itertools.izip() can offer a performance
boost and better memory utilization than zip(). It can be used almost anywhere
as long as the app doesn't demand a real list.
Raymond Hettinger