What does `a < b < c` mean in Python, and how many times is `b` evaluated?

## The grammar, not a special case for `<` Python's grammar defines a comparison as one expression followed by *any number* of `(comparison-operator, expression)` pairs. So `a < b < c` is a single comparison expression with two operators, not two nested expressions. The language reference gives the meaning directly: an expression of the form `a op1 b op2 c ... y opN z` is equivalent to `a op1 b and b op2 c and ... and y opN z`, **except that each expression is evaluated at most once**. That "at most once" clause is the whole interview question. Two properties follow from it. ## Property one: the middle expression is evaluated exactly once In `a < b < c`, the value of `b` is computed a single time and then used as the right operand of the first comparison and the left operand of the second. This matters the moment the middle expression is anything but a plain name: ```python def probe(label, value): print("evaluating", label) return value 1 < probe("b", 5) < 10 # prints "evaluating b" exactly once, then yields True ``` If Python re-evaluated the middle, that snippet would print twice. It does not. The consequence is that the "obvious" manual expansion is **not** an equivalent refactor: ```python f() < g() < h() # calls f, g, h at most once each f() < g() and g() < h() # calls g twice - different behaviour ``` If `g()` increments a counter, pops from a queue, advances an iterator, or costs a network round trip, those two lines do genuinely different things. When you need to break a chain apart, bind the middle to a local name first, preserving the original left-to-right evaluation order: ```python _a = a() _b = b() _a < _b and _b < c() ``` ## Property two: the chain short-circuits Because the desugaring is an `and`, evaluation stops at the first false comparison. In `5 < 3 < 1/0` the sub-expression `1/0` is never evaluated and the whole expression is simply `False` - no `ZeroDivisionError`. Operands to the right of a failed comparison are never computed, which is occasionally load-bearing: `x is not None and 0 < x` style guards can often be written as a chain where the cheap test comes first. Evaluation order within the chain is strictly left to right: operands are evaluated in source order, and each comparison is performed as soon as both of its operands exist. ## What the compiler actually emits You can watch the mechanism directly. `dis.dis("a < b < c")` shows the compiler evaluating `a` and `b`, duplicating the middle value on the stack, performing the first comparison, taking a conditional jump that abandons the rest of the chain when the result is false, and otherwise continuing with the saved copy of `b` as the left operand of the second comparison. There is no temporary variable in your code and no re-execution of the middle expression - the value simply stays on the stack. ## The contrast that makes it memorable In C-family languages, `a < b < c` parses as `(a < b) < c`: the first comparison yields 0 or 1 and *that* is compared with `c`. The expression compiles and almost never means what the author intended. Python deliberately rejected that reading, which is why the chained form is idiomatic here and a bug there. Note that Python will happily evaluate the C-style meaning if you write the parentheses yourself - `(1 < 2) < 3` is `True < 3`, which is `1 < 3`, which is `True` - because `bool` is a subclass of `int`. ## Using it well Chaining is at its best for interval tests, where it puts the bounded value visually between its bounds: * `0 <= index < len(items)` - the canonical bounds check. * `"a" <= char <= "z"` - a range test over single-character strings. * `start <= timestamp < end` - a half-open window, with the asymmetry visible at a glance. It reads poorly when the operands are long expressions, because the middle one appears once but is conceptually used twice; bind a name in that case. Chains longer than three operands (`a < b < c < d`) are legal but rare, and reviewers generally find them harder to verify than the explicit `and` form. Finally, note that a chain does not require the same operator throughout - mixing is legal and has a surprise or two in it, which is a separate topic from the evaluation semantics covered here.