Understanding Python List Comprehensions

The line looked elegant until the reviewer asked what it did with missing values, duplicate records, and a logging call hidden inside the expression. Python’s list comprehension had not failed. The code review had exposed a more useful question: was a compact line still the clearest way to build the result?

A list comprehension creates a new list from an iterable by combining an expression with one or more `for` clauses and optional conditions. Python’s official tutorial presents it as a concise and readable alternative to a loop for common transformations and filters in the data structures documentation. The important phrase is “for common.” A comprehension is a construction tool, not a universal replacement for every loop.

The first version has a clear job

Imagine a small project that converts raw scores into a list of passing scores. The original loop says exactly what it is doing:

scores = [42, 78, 91, 65, 33]
passing = []

for score in scores:
    if score >= 60:
        passing.append(score)

print(passing)  # [78, 91, 65]

The comprehension expresses the same construction in one line:

passing = [score for score in scores if score >= 60]

Read it from left to right as: put `score` in a new list, for each `score` in `scores`, if the score is at least 60. The expression, loop, and condition are all visible. This is a good fit because the result has one purpose and the reader does not need to remember hidden steps.

The second version adds a transformation

The reviewer now asks for labels instead of raw numbers. The expression changes, but the mental model remains stable:

labels = [f"pass:{score}" for score in scores if score >= 60]
# ['pass:78', 'pass:91', 'pass:65']

The `for` clause still chooses the source values, the condition still filters them, and the expression now transforms each value before placing it in the result. This is where comprehensions are especially readable: the operation is local, and there is no hidden state to update.

Our guide to Python `for` loops provides the longer-form foundation. A comprehension is easier to understand after you can expand it mentally into a loop. If the shorter syntax feels like a puzzle, the loop is not “less Pythonic”; it is the reference version that makes the behavior explicit.

The warning sign: the line starts carrying decisions

Suppose the project receives dictionaries instead of numbers. Each record can be incomplete, its status may have different spellings, and the output needs to include a normalized label:

records = [
    {"name": "Ana", "status": "active"},
    {"name": "Ben", "status": "paused"},
    {"status": "active"},
    {"name": "Dee", "status": "ACTIVE"},
]

active_names = [
    record["name"].strip().title()
    for record in records
    if record.get("status", "").lower() == "active"
    and record.get("name")
]

This still works, but the expression now performs lookup, normalization, filtering, and formatting in one visual unit. A reader has to inspect evaluation order and repeat the missing-data logic mentally. The issue is not line length alone. The issue is that several distinct decisions are now compressed into the same syntax.

Code review symptom one: nested conditions

selected = [
    transform(item)
    for group in groups
    for item in group.items
    if item.enabled
    if item.owner
    if is_allowed(item.owner)
]

Python supports multiple `for` and `if` clauses, and the order matters. The official tutorial shows that nested comprehensions correspond to nested loops. That power is useful for a small, obvious flattening operation. It becomes harder to review when the reader must trace several collections, permissions, and transformations at once.

Expand the behavior when the conditions represent business rules:

selected = []

for group in groups:
    for item in group.items:
        if not item.enabled:
            continue
        if not item.owner:
            continue
        if is_allowed(item.owner):
            selected.append(transform(item))

The loop uses more lines, but each gate has a nameable place. That matters when the rule changes or an error needs to be logged.

Code review symptom two: side effects hiding in a constructor

A comprehension is intended to construct a collection. Using it only to trigger an effect produces a list that nobody needs:

# Technically executes, but throws away the new list
[print(score) for score in scores]

Use a loop for the side effect:

for score in scores:
    print(score)

The second version tells the reader that printing—not list construction—is the purpose. The same warning applies to database writes, file operations, network calls, logging, and mutation. A compact expression should not hide an action just because Python permits the syntax.

List or generator? The brackets change the contract

Changing square brackets to parentheses creates a generator expression:

list_values = [n * 2 for n in range(1_000_000)]
generator_values = (n * 2 for n in range(1_000_000))

The list comprehension evaluates the expression and stores all one million results immediately. The generator expression produces values lazily as the program requests them. It is often appropriate when you need to iterate once and do not need indexing, slicing, or repeated traversal.

The distinction is part of Python’s language model, not a trick specific to one library. The official reference for generator expressions describes the parenthesized form as an expression that yields values on demand. That makes the choice a contract about timing and reuse, not merely a preference for square or round brackets.

Do not describe this as “generators are always better for memory.” The generator changes when work happens and what operations are available. If a function needs the result three times, random access, or a stable snapshot, materializing a list may be the clearer and more appropriate contract.

Code review symptom three: the “one breath” test fails

A useful practical test is to read the comprehension aloud. If you can explain the expression, source, and condition in one breath, it may be a good fit. If you need to pause to explain a nested loop, a fallback value, a permission check, and a formatting function, expand it or split the work.

This is not a performance rule. A longer loop is not automatically faster, and a shorter comprehension is not automatically slower. For small inputs, performance differences are often irrelevant compared with clarity. Use measurement when performance matters, but use readability as the default design constraint.

Our article on Python string methods shows why chained transformations can become difficult to reason about. A comprehension can create the same problem when it combines filtering, conversion, and formatting without a visible boundary between them.

Set and dictionary comprehensions are related, not interchangeable

words = ["cat", "horse", "cat", "bird"]

unique_lengths = {len(word) for word in words}
word_lengths = {word: len(word) for word in words}

The first expression creates a set, so duplicate lengths collapse. The second creates a dictionary, so each word becomes a key. Our Python dictionaries guide explains the key-value model behind the second result. The visual similarity is helpful, but the result type changes the behavior: set membership, dictionary keys, and list order are different contracts.

When the loop is the correction

The final version of the review does not ban comprehensions. It makes the rule explicit:

active_names = []

for record in records:
    status = record.get("status", "").lower()
    name = record.get("name")

    if status != "active" or not name:
        continue

    active_names.append(name.strip().title())

Now a future requirement has a place to go. If the project must record malformed records, the loop can log them. If normalization changes, the transformation has a visible line. If a test fails, the reviewer can inspect the state without mentally unpacking a dense expression.

The comprehension remains ideal for the simpler version:

active_names = [
    name.strip().title()
    for name in names
    if name
]

The choice is not “Pythonic versus un-Pythonic.” It is whether the expression communicates the operation the reader needs to maintain. Python’s style guidance also places readability and consistency above clever compression, which is why the clearest loop can be the more idiomatic choice for a rule-heavy section in PEP 8.

Questions that appear in review

Let the result be concise, not the reasoning

List comprehensions are a strong Python feature because they can express a simple construction close to the way a reader describes it: transform each item, keep the ones that pass, and build a new list. They become a weak choice when the line conceals state changes, business rules, effects, or several unrelated decisions.

When a code review asks you to expand a comprehension, it is not necessarily asking for less elegant Python. It may be asking you to make the reasoning visible again.

Continue from comprehensions to Python’s key-value structures →

Alex Carter

Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.