[version_five]

Re unpacking with * one I use often is when you have a list of types of coordinates you want to plot, i.e.

  # z = [(x0,y0), (x1,y1) ...]

You can do

  import matplotlib.pyplot as plt
  plt.plot(*zip(*z))

I spent years doing

  x = [t[0] for t in z] # etc

before I realized this.

[jacurtis]

I'd argue that your original approach is actually better than your new approach.

Using a list comprehension, such as your original approach, is pretty easily understood by anyone writing python and is easy to follow, it is also quite terse.

Your recursive unpacking zip thing is much harder to understand and read. This reminds me of the type of stuff you find in the codebase years later when the person who wrote it is long gone and you find a comment next to it that says:

# No idea why this works, but don't touch it

One of the problems I have with python is that there are a million super creative ways to do stuff, especially using less known parts of the language. People love to get super creative with it, but usually the simplest solution is actually the best one, especially when working on a team.

In your example above, you aren't even saving any real space. Both approaches can be done inline, the list comprehension is maybe a few extra characters. You're not really saving anything, just making it harder to read and maintain by others.

When I moved from a company that wrote in Python to one that wrote in Golang, I found that the restrictions that Golang offers is a huge benefit in a team. Because you don't have access to all these crazy language components that python has, the code written in Go would be almost identical regardless of who wrote it. Of course everything in Golang is far far more verbose than Python, but I actually found it 100x more maintainable.

In the python codebase it was very easy to tell who wrote different parts of a codebase without looking at the git blame, because there was almost a "voice" with the style of writing python. But in Golang it was more restrictive which meant that the entire codebase was more cohesive and easily to jump around.

[abecedarius]

The need actually comes up a lot to transpose a list of lists. That zip can do it is not hard to visualize and it's an idiom worth learning. If it still seems unclear, you can name things to help:

    columns = zip(*rows)

or

    def transpose(list_of_lists): return zip(*list_of_lists)

But anyway, yeah, tastes differ, it's fine if we disagree. I do agree that Python has gotten uncomfortably complex. But this is a very old feature from simpler times and does not add any syntax or metaprogramming features, it's just an already needed function.

[andelink]

Not saying I disagree with you, but I do want to note that the specific example of unzipping a list using `zip` has been in the official zip docs [1] as long as I can remember, and as such, should be commonly understood by Python developers.

[1] https://docs.python.org/3/library/functions.html#zip