List comprehensions

What it is and why it exists

A list comprehension is a form of list display. It writes “iterate, optionally filter, calculate, and append to a new list” as one expression, with the basic form [expression for item in iterable if condition]. The result is a new list object even when the input isn’t a list.

The input only needs to be an iterable , such as a list, tuple, range, dictionary view, or generator. Each item that passes the condition causes the leading expression to be evaluated once, and the result is placed in traversal order. Rejected items don’t enter the result, and the leading expression isn’t evaluated for them.

The syntax keeps a simple mapping and filter from being scattered across several statements. An ordinary loop first creates an empty list, then needs a for, a condition, and append(); a comprehension keeps that data rule together. You should still be able to answer two questions quickly: where does the input come from, and which values enter the result?

You’ll see list comprehensions in data cleaning, API response shaping, test fixtures, and parameter combinations. They fit when the task naturally reads as “produce zero or one output for each input.” If one input may append several different results, or the body updates outside state, an ordinary loop is usually more direct.

A list comprehension builds only a list. Dictionary and set comprehensions and generator expressions reuse a similar clause structure, but differ in result type, duplicate handling, and evaluation timing. Calling all of these forms “list comprehensions” hides behavior that matters.

How it works

The result expression comes first, followed by at least one for clause and then zero or more for or if clauses. Execution doesn’t start with the visually leftmost expression; the for and if clauses expand from left to right. The result expression is evaluated and appended once only when execution reaches the innermost point.

The following two forms have the same logic. Clause order in the comprehension matches the outside-to-inside order of the expanded statements:

[transform(item) for item in source if keep(item)]

The loop visits, filters, and finally transforms and appends:

for item in source → if keep(item) → result.append(transform(item))

That order affects correctness. A filter can prevent the result expression from running, so a dangerous or costly transformation can be limited to valid input. Conversely, if both the filter and result call the same function, it runs twice for accepted items; stateful calls may even produce inconsistent answers.

Multiple for clauses are nested loops. [pair for left in lefts for right in rights] holds one left, traverses all of rights, and only then advances to the next left. Later clauses can use names bound by earlier clauses; swapping the clauses may reorder the output or reference a name before it exists.

A trailing if is a filter clause and has no else. A conditional expression occupies the result position and has the form when_true if condition else when_false, so each input can produce one of two results. Both forms may appear together: the trailing condition decides whether to keep an input, then the leading condition decides what an accepted input produces.

A list comprehension consumes its input immediately and constructs the complete result. It fits when you need to index, traverse repeatedly, or modify that result later. If the values go straight into a one-time consumer such as sum(), any(), or all(), a generator expression can avoid constructing an intermediate list.

Read outward from for

When a comprehension spans several lines, don’t infer execution from the visual order of the result expression. Find the first for, indent each later clause in order, and finally treat the leftmost expression as the argument to the innermost append(). The same reading method works for list, set, and dictionary comprehensions.

Check a comprehension in this order:

1. Find the input after the leftmost for and identify the values it provides.
2. Record the iteration target’s unpacking shape, such as for key, value in mapping.items().
3. Apply later for and if clauses from left to right, checking that every name is already bound.
4. Evaluate the result expression and verify that it runs once for every path that reaches it.
5. Use the delimiters to identify the result container, then check whether the caller relies on order, duplicates, or repeated consumption.

Each part has one job in the basic form:

The syntax allows consecutive if clauses, but they are simply nested filters. [x for x in values if ready(x) if valid(x)] has the same acceptance rule as joining those conditions with and, including left-to-right short-circuiting. Separate clauses can make a dependency clearer when the first condition excludes values that the second condition can’t handle.

Choose by result cardinality

When every input produces exactly one output, you need only a transformation expression and one for. Add a filter when each input produces zero or one output. Add another for when one input produces several outputs, but only if the nested relationship is simple and stable enough to read in compressed form.

A comprehension becomes awkward when branches append different numbers of results. Grouping, accumulation, early exit, and per-item recovery all need statement-level control flow and shouldn’t be forced into one expression. The test isn’t whether the code can be written as a comprehension; it is whether its expansion still has one clear data path.

Examples

These four examples progressively add filtering, a conditional expression, multiple iteration clauses, and an assignment expression. Each program runs independently, and the output shown below came from the local python3 runtime.

Transform and filter

Payment status is the filter, and receipt text is the transformation. An unpaid order doesn’t evaluate the formatting expression and doesn’t appear in the new list.

The comprehension preserves the source order. It doesn’t modify orders, although result items aren’t always isolated from input objects; this expression creates new strings, so there is no shared mutable object here.

When expanded, for order in orders is outermost, if order["paid"] sits inside it, and formatting plus append happen last. Reverse-expanding a more complicated comprehension this way usually makes its execution order obvious.

Conditional expression and filter clause

This example filters out None and negative values, then discounts prices of at least 20. The leading if ... else ... chooses one result for every retained price, while the trailing if determines whether to retain a price.

prices = [12, 0, None, 27, -3, 40]

normalized = [
    round(price * 0.9, 2) if price >= 20 else float(price)
    for price in prices
    if price is not None and price >= 0
]

print(normalized)

[12.0, 0.0, 24.3, 36.0]

None and -3 are rejected, so they don’t reach numeric comparison or transformation. A simple if price would be wrong because truth-value filtering would also drop the valid zero; the code checks missing data and the accepted range explicitly.

A conditional expression always needs else. If the requirement is only to retain high prices, write [price for price in prices if price is not None and price >= 20]. Use the conditional expression when every valid price remains but requires a different transformation.

Multiple for clauses

Multiple clauses can flatten one level of nested data. This code visits departments, then members of the current department, and finally filters active members; the second for can use department, which the first one bound.

departments = [
    {
        "name": "sales",
        "members": [
            {"email": "[email protected]", "active": True},
            {"email": "[email protected]", "active": False},
        ],
    },
    {
        "name": "support",
        "members": [
            {"email": "[email protected]", "active": True},
        ],
    },
]

addresses = [
    f'{department["name"]}:{member["email"].lower()}'
    for department in departments
    for member in department["members"]
    if member["active"]
]

print(addresses)

['sales:[email protected]', 'support:[email protected]']

Department order determines the first part of the output order, and member order within each department determines the rest. A comprehension neither sorts nor deduplicates automatically; if the requirements call for either, choose sorted() or a set explicitly and check whether that changes the business meaning.

Two for clauses are already near the limit of what most readers can parse at a glance. If you also need several filters, exception handling, or intermediate logging, expand the code into named loops; fewer lines aren’t a reason by themselves to use a comprehension.

Compute once

When filtering needs a converted value and the result needs it too, calling the parser twice wastes work. An assignment expression , :=, can retain the value in the filter, but its scope rule must be understood.

def parse_score(raw):
    try:
        return int(raw)
    except ValueError:
        return None


raw_scores = ["18", "skip", " 27 ", "-3", "42"]

scores = [
    score
    for raw in raw_scores
    if (score := parse_score(raw)) is not None and score >= 0
]

print(scores)
print(f"last parsed: {score}")

[18, 27, 42]
last parsed: 42

Every raw string calls parse_score() once. The condition excludes None first, so short-circuit evaluation compares score >= 0 only after parsing succeeds; a negative number parses but fails the range condition.

score still exists after the comprehension because an assignment expression in a comprehension binds its target in the containing scope. That is a deliberate special rule, so don’t assume this name behaves like a non-leaking temporary. If the binding surprises a reader, an ordinary loop or small helper is clearer.

Pitfalls

Hiding side effects in the result expression

A comprehension doesn’t turn side effects into a batch transaction. If a call fails halfway through, earlier calls may already have taken effect even though assignment of the list never completes. An explicit loop expresses ownership better when you need rollback, retries, or per-item error records.

Writing a filter as a conditional expression

It helps to name the operation in plain language: “filter” maps to a trailing clause, while “replace” or “label” maps to a leading conditional expression. When both appear, verify that filtered inputs never execute the result expression.

Repeating work in the filter and transformation

Check exception semantics too. If the parser raises, the filter doesn’t skip that item; it terminates the whole comprehension. For per-item recovery, have a helper return an explicit result type or use a narrowly scoped try block in a loop.

Losing the domain order in nesting

Don’t confuse a nested comprehension with multiple for clauses. [[transform(x) for x in row] for row in matrix] preserves rows, while [transform(x) for row in matrix for x in row] flattens one level. Different delimiter shapes produce different result shapes.

Materializing a list for one consumer

A generator expression isn’t automatically better. It is usually single-use, errors may move to iteration time, and retaining it may extend an input resource’s lifetime. Choose the boundary from how the result is consumed, not just from input size.

Creating deferred functions inside a comprehension

An immediately evaluated result expression doesn’t have this timing gap; the problem appears when the result itself is a deferred function. Run every callback after the comprehension in tests and use at least two distinct inputs, because one element can’t expose shared binding.

This is a closure late-binding issue, not a list-copying problem. Don’t copy the whole input object automatically; first decide whether the callback should retain the object reference or one immutable field value from creation time.

Further reading

• Python tutorial: List Comprehensions
• Python language reference: list, set, and dictionary displays
• PEP 202: List Comprehensions
• PEP 572: Scope of the target