Which Python operators can chain, and does `x != y != z` mean all three differ?

## The operator set Python has ten comparison operators, and the grammar treats them as one interchangeable class: `<` `<=` `>` `>=` `==` `!=` `is` `is not` `in` `not in` They all share a single precedence level, they all bind tighter than the boolean operators `not`, `and` and `or`, and - the point of this question - **any of them may appear in a chain**. Chaining is not a special rule bolted onto `<`; it is how the grammar defines a comparison expression. A run of `operand op operand op operand` means the conjunction of the adjacent pairs, with each operand evaluated only once. ## Surprise one: `!=` does not mean "all different" Because a chain is just a conjunction of *adjacent* pairs, `x != y != z` expands to `x != y and y != z`. The pair `(x, z)` is never compared: ```python 1 != 2 != 1 # True - and 1 == 1 ``` Writing that chain to assert three distinct values is a real and quiet bug; the expression is `True` for exactly the input it was meant to reject. For genuine distinctness, compare the count of a set against the number of values, or spell out all three pairs. The same caveat technically applies to `==`. `a == b == c` implies `a == c` only if `__eq__` behaves transitively, which the language does not enforce - a type is free to define equality however it likes, and float NaN is the standard counterexample in the other direction, being unequal to itself. For ordinary types the chain reads as intended, but the guarantee comes from the types, not from the chaining. ## Surprise two: membership and identity chain too This is where chaining stops being a convenience and starts being a trap, because the operators involved do not look like they belong in a chain: ```python 1 in [1, 2] == True # False ``` A reader parses this as "is `1 in [1, 2]` equal to `True`?" and expects `True`. Python parses it as a two-link chain: `1 in [1, 2] and [1, 2] == True`. The first link is true, the second compares a list with a bool and is false, so the whole expression is `False`. Mixed chains such as `0 < 1 in [1, 2]` (meaning `0 < 1 and 1 in [1, 2]`) are legal in the same way. The practical rule: when a comparison operand is itself the *result* of a comparison, parenthesise it. `(1 in [1, 2]) == True` says what the author meant - though comparing to `True` at all is usually redundant, since `in` already yields a bool. ## `is not` and `not in` are single operators `is not` and `not in` are each one operator token, not a `not` applied to a separate expression. That matters for two reasons. There is no separate method behind the negated forms - a type that supports `in` gets `not in` automatically - and the chaining rules apply to them just as they do to `<`. Because comparison binds tighter than the boolean `not`, the expression `not a is b` parses as `not (a is b)` and produces the same value as `a is not b`. They are interchangeable in result but not in readability, and Python's style guidance is explicit that `is not` is preferred; the same holds for `not in` over `not x in y`. A reviewer seeing `not x is None` should ask for `x is not None`. ## Style guidance worth stating in review * Chains of homogeneous ordering operators are idiomatic and readable: `0 <= i < len(items)`, `start <= ts < end`. * Chains that **mix** operator families - especially one that pulls `in`, `is` or `==` into a chain with an ordering operator - are almost always accidental. Parenthesise or split them. * A chain of `!=` is a smell; state what you actually mean about distinctness. * Prefer the single-token `is not` and `not in` forms over negating the whole comparison. None of this is exotic knowledge that gates an offer, but it explains a class of quiet bug that survives review precisely because the code looks like it says something else.