A ternary expression picks one of two values based on a condition, all in a single line. It's the same idea as an if/else block, except it's an expression (it has a value) instead of a statement (it just runs code). That difference is what lets you use it inside variable assignments, function arguments, f-strings, and list literals where a full if/else block would be illegal.

Python writes the ternary in a slightly unusual order:

The condition sits in the middle. That feels strange if you've seen the C-style condition ? a : b form in another language, but Python's order is intentional: it reads almost like English. "Give me 'In Stock' if quantity > 0 else 'Out of Stock'."

Here it is on a real check:

Python evaluates the condition quantity > 0. If it's true, the whole expression takes the value to the left of if. If it's false, it takes the value to the right of else. There's no third option, no fall-through, and the else clause is mandatory.

The same idea written as a regular if/else statement looks like this:

Five lines instead of one, and the variable status gets assigned in two different places. The ternary version assigns once, which is part of why it reads more cleanly when the logic is this simple.

Here's the evaluation flow Python actually follows:

Only one of the two value branches is ever evaluated. If the condition is true, Python never even looks at the else value. That short-circuit behavior matters when one of the branches would be expensive or would raise an error.

The condition prices is falsy because the list is empty, so Python returns 0 without ever evaluating prices[0]. If both sides were always evaluated, this code would crash with an IndexError. The ternary lets you write a safe one-liner for this kind of guard.

The ternary earns its keep when you need a value inline, somewhere that an if/else block can't go. Variable assignment is the most common case, but it's not the most interesting one.

Inside Variable Assignment

This is the everyday use. You want to compute a value based on one condition and bind it to a name:

One line, one assignment, no branching block. The reader's eye lands on shipping = ... and immediately sees the rule: free above 50, otherwise $4.99.

Inside f-strings

f-strings let you embed any expression inside {...}, and that includes ternaries. This is the cleanest way to vary a piece of a message without building it up in pieces:

Without the ternary, you'd either build the status in a separate variable first or split the print into an if/else. Inline like this, the message stays in one place and the rule for the variable part is right where it's used.

The same trick works for pluralization:

The ternary returns either 's' or the empty string, and the f-string drops it right next to the noun. This is one of the friendliest English-pluralization tricks in Python.

Inside Function Arguments

A ternary lets you pick which value to pass without building a temporary variable:

The discount percentage flips based on is_member, all without an intermediate percent = ... line. Use this sparingly: if the condition is more complex than a single comparison, pulling it into its own variable is friendlier to the reader.

Inside List and Dict Literals

You can put a ternary inside any element of a list or value of a dict. A common pattern is a status summary that mixes computed and conditional values:

For the available field specifically, you'd usually just write quantity > 0 directly (since comparisons already return True or False), but the ternary form makes the intent obvious when the values aren't booleans.

Inside List Comprehensions

This is where ternaries get genuinely powerful. A comprehension can use a ternary to transform each element based on a condition:

Each price runs through the ternary, and the result goes into the new list. The ternary sits before the for, which is the position that says "compute this value for each element". This is very different from the filter form, which puts the condition after the for:

The first list keeps every element and transforms it. The second list keeps only some elements and leaves them as-is. Both forms are useful. The placement of if tells you which one you're looking at: before for means transform, after for means filter.

You can combine the two when you need to transform and filter:

The if price > 10 filter drops 9.99 from the source. Then the ternary labels each survivor based on whether it's above 30. Read it left to right: "give me 'premium' if price > 30 else 'regular', for each price in prices where price > 10."

If you've used another language with a cond ? a : b form, Python's order can feel backwards. The reasoning behind it is readability: the most common value, the one you actually expect, comes first.

Compare these two readings:

versus the C-style alternative (not valid Python):

The Python version reads like a sentence. "Status is 'In Stock' if quantity > 0, else 'Out of Stock'." Your eye lands on the value first, which is usually what you care about. The condition is the qualifier.

This ordering also discourages a common abuse: writing a ternary purely for terseness when an if/else block would be clearer. Python's syntax makes long ternaries awkward to read, which nudges you toward keeping them small.

You can nest a ternary inside another ternary. Python allows it, and it works:

This reads as "'In Stock' if quantity > 10, otherwise ('Low Stock' if quantity > 0, otherwise 'Out of Stock')". The else branch of the outer ternary is itself a full ternary. Python associates them right-to-left, so the chain naturally reads top to bottom.

For one level of nesting, this can still be readable. Past one level, it falls apart fast.

It works, and with the line breaks it's not unreadable, but it's actively hostile to anyone who has to maintain it. Every reader has to mentally rebuild the cascade to figure out which branch a given value lands in. The if/elif/else form handles this exact case far more clearly:

A few extra lines, but each branch is on its own line with its own condition. Adding a fifth tier later is trivial. The cascade structure is visible at a glance.

The rule of thumb: use a ternary when there are exactly two outcomes. The moment you reach for a second if, switch to if/elif/else. Your future self (and anyone reviewing your code) will thank you.

Ternaries are simple, but a few patterns trip people up regularly.

Confusing the Argument Order

If you've used C, Java, JavaScript, or many other languages, you've seen condition ? a : b. Python's order is a if condition else b. Mixing them up usually produces code that looks fine but does the opposite of what you wanted:

The author meant "if there's no stock, say Out of Stock". They wrote a condition quantity > 0 and then put the out of stock label in the position that runs when the condition is true. The fix is to flip either the values or the condition:

The trick to avoiding this: read the ternary out loud, treating if as "when". "Status is In Stock when quantity is greater than zero, else Out of Stock." If the sentence describes what you actually want, the ternary is right.

Using a Ternary for Side Effects

A ternary is an expression. It produces a value. It is not a way to run one of two pieces of code. Using it for side effects works (Python won't stop you), but it's bad style and confuses anyone reading the code:

What's wrong with this code?

The output is correct, but the line is doing something strange: it's evaluating a ternary purely to call one of two functions for their side effects, then throwing away the return value. The whole expression evaluates to None (because list.append() returns None), and that None goes nowhere. This is exactly the case if/else was designed for:

Same result, clearer intent. Use a ternary when you need a value. Use if/else when you need to do something.

Forgetting the else

Unlike the if statement, the else clause in a ternary is not optional. There is no such thing as a one-armed ternary in Python:

If you only want to do something when a condition holds (and leave a variable alone otherwise), use an if statement, not a ternary. Or, if you want a default value, supply it explicitly:

Now the ternary covers both outcomes, and the else makes the "otherwise" case explicit.

Over-Nesting

This is the big one. A ternary inside a ternary inside a ternary is technically valid Python and almost always a mistake:

Compared to the if/elif/else form, this gives no readability benefit and a noticeable cost: every reader has to walk the chain to verify which branch a given input hits. If you find yourself adding a second else ... if, stop and write the block form instead.