Once Python list comprehensions click, you start seeing them everywhere — and your code gets noticeably shorter and clearer for it. They are one of the features that make Python feel like Python. But they are also easy to overuse, so let us cover both how they work and when to stop.
The basic shape
A list comprehension builds a new list from an existing iterable in a single expression. Here is the classic before-and-after:
# The long way
squares = []
for n in range(10):
squares.append(n * n)
# The comprehension
squares = [n * n for n in range(10)]Read it left to right: “give me n * n, for each n in the range.” Once your eye learns that rhythm, the second version is faster to read, not slower.
Adding a condition
You can filter with an if at the end:
# Only even squares
even_squares = [n * n for n in range(10) if n % 2 == 0]That reads as “give me n * n for each n, but only when n is even.” Filtering inline like this replaces a loop-plus-if block with one honest line.
Not just lists
The same syntax builds dictionaries and sets, which people forget:
# Dict comprehension
lengths = {word: len(word) for word in words}
# Set comprehension
unique_first_letters = {word[0] for word in words}And if you wrap the expression in parentheses instead of brackets, you get a generator that produces items lazily — perfect for huge sequences you do not want to hold in memory all at once.
Knowing when to stop
Here is the part tutorials skip. Comprehensions are for building a collection from a transformation and an optional filter. The moment you find yourself nesting three for clauses or cramming a ternary inside a filter, readability falls off a cliff:
# Technically valid, genuinely unpleasant
matrix = [[row[i] for row in grid] for i in range(len(grid[0]))]If a teammate has to stop and decode it, a plain loop is the better choice. Clever is not the goal; clear is.
The if/else placement that trips everyone
Python has two different if positions in a comprehension, and they mean different things — this is easily the most common comprehension confusion. An if at the end filters items out. An if/else at the beginning transforms every item conditionally:
# FILTER: keep only positives (if at the end)
positives = [n for n in numbers if n > 0]
# TRANSFORM: replace negatives with zero (if/else at the front)
clamped = [n if n > 0 else 0 for n in numbers]The first produces a possibly-shorter list; the second always produces the same length. Mixing them up produces syntax errors (“why can’t I put else at the end?”) or silent logic bugs. The mnemonic: filtering happens after the loop clause, transforming happens in the expression. You can also combine them — [n if n > 0 else 0 for n in numbers if n != 13] — though at that density, consider whether a loop reads better.
Real-world patterns worth stealing
Beyond squares-of-numbers examples, comprehensions earn their keep in everyday data wrangling:
# Clean user input: strip whitespace, drop empties
names = [s.strip() for s in raw_names if s.strip()]
# Flatten one level of nesting
flat = [item for sublist in nested for item in sublist]
# Invert a dictionary
by_id = {v: k for k, v in name_to_id.items()}
# Pull one field out of a list of dicts (API responses)
emails = [user["email"] for user in response["users"]]
# Quick lookup set for fast membership tests
valid_ids = {row.id for row in rows}That flattening pattern deserves a note: the for clauses read left to right in the same order as nested loops would — for sublist in nested first, then for item in sublist. Everyone writes it backwards exactly once.
Performance: real but usually beside the point
Comprehensions are genuinely faster than equivalent append loops — typically 20–30% — because the looping happens closer to C level and skips repeated method lookups. But the more important performance choice is list vs generator. sum(n * n for n in range(10_000_000)) computes the same answer as the list version while holding one number in memory instead of ten million. The habit: if you’re only iterating over the result once — feeding sum(), max(), any(), a for loop — use a generator expression. Build an actual list only when you need to index it, reuse it, or know its length.
One more modern corner: the walrus operator lets you compute a value once and use it for both filtering and output — [y for x in data if (y := expensive(x)) is not None] — replacing the old pattern of calling the expensive function twice. Use sparingly; it’s powerful and slightly cryptic.
A style checklist before you commit one
A quick gut-check that keeps comprehensions on the right side of clever: it fits on one line (or two with a clean break), it has at most one for and one condition, the expression at the front is simple enough to read aloud, and it has no side effects — comprehensions that call functions for their effects rather than their return values ([print(x) for x in items]) are widely considered an antipattern; that’s what a plain loop is for. If your comprehension passes all four, ship it. If it fails two or more, it wants to be a loop, or the transformation logic wants to be extracted into a named helper function — [normalize(row) for row in rows] stays readable no matter how complex normalize gets on the inside.
Frequently asked questions
Are nested comprehensions ever okay? One level of nesting for a simple, well-known pattern (flattening, a small matrix) is fine. Two levels, or nesting with conditions, is where even experienced Python developers slow to a crawl reading it — that’s the signal to use loops with named intermediate variables.
Why did my comprehension variable leak… or not? In Python 3, the loop variable is scoped to the comprehension — n doesn’t exist afterward. (In Python 2 it leaked into the enclosing scope, a wart long since fixed.) If you’re seeing tutorials mention leakage, they’re historical.
List comprehension or map/filter? Comprehensions are the idiomatic Python choice — [f(x) for x in xs] over list(map(f, xs)) — mostly on readability grounds. map wins only when you already have a ready-made function and feel the parens-over-brackets style; there’s no meaningful performance gap to chase.
The takeaway
Python list comprehensions shine when they replace a small, obvious loop that just maps or filters. Use them there and your code reads beautifully. When the logic grows branches and nesting, write the loop — your future self reviewing this at 5 p.m. on a Friday will thank you.
