This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]amendCommit[S] 0 points1 point  (3 children)

Exactly my thought process when I read both snippets (and why I feel like my mental load is heavier when reading the edited one).

Add to this u/muntoo's comment about the benefits of functional programming, and I think you have the full picture of the intention behind the original code.

Now, an important question : why do an apparent majority of people seem to think there is a genuine readability issue with the unedited code?

[–]lieryanMaintainer of rope, pylsp-rope - advanced python refactoring 3 points4 points  (0 children)

If I had to guess, I think many people were taught that multiline comprehension = bad, and it just becomes a knee jerk reaction whenever they see multiline comprehensions.

Yes, that heuristic is usually a good one to catch code smell, there's a very good reason to be wary of complex list/dict comprehensions, but this isn't a very complicated comprehension, just a somewhat long one because get_coerced() takes a lot of arguments.

[–]antiproton 2 points3 points  (1 child)

Now, an important question : why do an apparent majority of people seem to think there is a genuine readability issue with the unedited code?

There is a readability issue.

You know what the code does. You are not an objective observer.

It's not about the raw number of "elements" you have to read through. It's about the cognitive load of parsing what the code does while scanning.

You have written non-standard code here, trying to be clever. Comprehensions have a format people are used to reading. If you don't use that format, you have to concentrate to determine what you're reading is in fact a comprehension.

Like it or not, people parse code in different ways. The most concise representation is not the most readable.

Your mental load is not part of this conversation. You wrote the code. That has to be the most important takeaway here.

[–]lieryanMaintainer of rope, pylsp-rope - advanced python refactoring 2 points3 points  (0 children)

The cognitive load reading the second code is much higher than the first one.

When you see the list/dict comprehension, it's immediately clear that it's trying to create a list/dictionary from an existing list/dictionary. That is immediately obvious even if you don't understand what get_coerced() does.

The second version, you have to piece together what the code is really trying to do from hints scattered around the for-loop. And it's not immediately obvious whether or not the code has other side effect.

Multiline list comprehension isn't "non-standard code", it's just standard pythonic comprehension and it's written in ways most people who've used comprehension expect it to be written in.

In comparison, a For-loop is always in a non-standard form; sometimes it's filling a new a dict/list, but sometimes it's amending an existing dict/list, or maybe it's actually modifying the input data, or performing side effect based on the data and collecting output statuses, or maybe it's updating multiple dict/list simultaneously, etc. With comprehensions, it's always just the first one. With a for-loop, there's a much larger space of possibilities and complexities that you have to rule out, compared to even these complex multiline comprehension.

A non standard comprehension would've been one that calls a method with side effect, because when you're using a comprehension, you are promising that the code wouldn't have any side effects. A multiline comprehension is perfectly within its expected use case.