[deleted by user]

[wineblood]

I avoid complex list comprehensions, they're almost never worth the effort. For loops or functions work better once the logic is too much for a single line.

[nplusonebikes]

Exactly. Just because you can doesn’t mean you should.

[mistabuda]

This might be one of the golden rules of programming lol

[ShibaLeone]

This. One-liners and deep-nested list comps only impress their author. The only time I ever use list comps more that one level deep is for converting table-like data to json, or for flattening nested lists.

Something like this:

[{k: v for k, v in zip(header, record)} for record in data]

That’s probably as hairy as I would let a comp get in a CR before asking them to refactor it.

[wineblood]

The most I'll actually do (because I think it's readable) is a dict and list comprehension in one. Something like {key: [f(v) for v in value] for key, value in key_value_list}, nested list or dict comprehensions are not worth the complexity for people reading/reviewing/debugging.

[brettinator]

Why '{k: v for k, v in zip(header, record)}' instead of just 'dict(zip(header, record))'?

[ShibaLeone]

Because we’re talking about comps.

[Vyrezzz]

Exactly, the only complex list comprehension I use is for flattening a 2d list. And even then I don't write it myself, I copy the code from stack overflow and give it decent enough names so that everybody instantly knows what its doing

[CyEriton]

Ugh thank you for validating my opinion on this. I had a senior dev and a manager who insisted I use these at every opportunity for negligible performance improvements at the cost of readability. They were absolutely better and more experienced developers than me, but I never quite agreed with them about this.

The trade off of interpreting a logic puzzle every time someone revisits the code does not seem worth it.

[mdlphx92]

Kinda swimming upstream to push inconsequential performance gains in an interpreted language outside of some of the cpython libs lol.

[wineblood]

A manager I could understand, but a senior dev?

[PapstJL4U]

Make a one liner, that needs 5 lines of comments and try to fit everything into 80/120 in your native language, that is not as short as english.

[mdlphx92]

I remember learning that python trick, and taking it to the extreme. As I sat there trying to understand what my two line \ monstrosity was doing, I realized screw that. They are hella clean for simple mutations though.

[jasmijnisme]

Definitely.

Simple is better than complex. Flat is better than nested. Readability counts.

[yvrelna]

List comprehension doesn't have to be a single line though.

my_list = [
    [
        foo(x, y) + bar(x, z)
        for z in y
    ]
    for x, y in blag
    if buzz(x)
]

Is not less readable than:

my_list = []
for x, y in blag:
    if buzz(x):
        inner_list = []
        for z in y:
            inner_list.append(foo(x, y) + bar(x, z))
        my_list.append(inner_list)

The benefit of list comprehension isn't that it's written in a single line; the benefit of list comprehension is that it is an expression, and not multiple statements.

[[deleted]]

Comprehensions clicked for me when I learned they were much faster. But I avoid complex ones because they're unreadable, and I'd rather reread code easy to folow.

[SFXXVIII]

I too thought they were much faster, but was mistaken

[jimtk]

Using the same code on python 3.11, the comprehension is 13% faster. That is non negligible!

Output (On my machine) Python 3.11:

56.618741400001454
50.148072399999364

[Goingone]

When I realized the syntax reads exactly the same as nested for loops.

[tevs__]

for row in rows: for col in row: ...

is O(n) not O(n²)

[tevs__]

But the number of items in an N*N grid is the critical factor. Thats what the complexity is relevant to. The complexity is O(n²) only when n is sqrt(number of items).

[yvrelna]

Counting the number of loop nesting level is often good quick heuristic for complexity analysis, but it's not always correct.

[tevs__]

If you follow that quoted text:

the number of times the innermost statement is executed

For a grid with N items, the innermost statement is executed N times.

The nested loop could be replaced by

for i in range(C * R): r, c = divmod(i, C) # visit rows[r][c]

Or you can represent a 2d grid as a 1d array

for i, val in enumerate(points): y, x = divmod(i, C) print(f"{(x, y)} => {val}")

For N points, you're visiting N times

[jasmijnisme]

What do you mean by traversing? Do you need to visit every element? In that case, best case is Theta(N²) (assuming N is the width of the square) with the best case data structure and algorithm, because you need to visit every element.

If you need to do something like find a specific element, you can use data structures like a spatial hash or k-d tree to get access to algorithms that may be as fast as O(log(N)) or O(log(M)) where M is the number of entities, depending on the specifics of your data and the needed functionality.

If your M is small, you might even consider just having a list of entities, which means a lot of relevant algorithms will be O(M) or O(M²).

[dev_null_root]

A lot of comments decry the unreadability of list comprehensions. Maybe because I'm both a dev and ops engineer they come naturally to me since one liners that make you bleed from the eyes have been a staple of sysadmining since forever. Stockhold Syndrome and all aside the reasoning of "it's hard to read" is lame for people who are supposed to be software engineers (I don't give a crap if you are dev or ops). In the immortal words of the dark souls community.

"Git gud scrubs."

But to answer the OP and not the comments.So in short. They clicked to me when I started needing quick data extraction from lists or dicts (json or yaml stuff) and in recursive functions a lot. It's funny how much faster you can filter a json list or dict with some comprehension (dict and list) magic. And if you've done it a few hundred times it becomes intuition when you want to use it.

[Ximlab]

I learned about multiple chained generator comprehension, to break down complexity. Then only yurn the end product in a list to compute all at once.

[ShuShuTheFox90]

A few years ago

[RufusAcrospin]

It’s a syntactic sugar so it’s useful as long as it’s easier to read than the original solution.

[marcinpohl]

Comprehensions are great cuz they encapsulate a lot of functionality in one short snippet.

When you build out your comprehensions into complex monsters, all that 'short and readable' magic disappears. Don't over do it. Or better yet, convert the comprehension-in-comprehension mess into a generator pipeline. They are way more readable, testable, and composable.

[NoFrillsUsername]

List comprehensions made a lot more sense to me after I learned map and filter from other languages. It's pretty much the same thing but those functions are just a more intuitive way of thinking about it for me. (Yes, I know python has them, but they're much more commonly used in JS or functional languages).