How does Python compare two tuples with <, and how does that drive sorted()?

### The algorithm, precisely Comparing two tuples with `<`, `>`, `<=` or `>=` runs a lexicographic comparison, the same rule that orders words in a dictionary. Python steps through both tuples in parallel: 1. At each position it asks whether the two elements are equal. 2. At the **first position where they are not equal**, it compares those two elements with the ordering operator and returns that answer. Every later position is ignored. 3. If it runs out of elements with everything so far equal, length decides: the shorter tuple is smaller. `('a',) < ('a', 0)` is `True`. Equality (`==`) works the same way but requires equal lengths and all positions equal. Two details of the walk matter in practice. First, the equality step uses an identity shortcut: an element that *is* the same object is treated as equal without calling `__eq__`. That is why `t = (float('nan'),)` satisfies `t == t` even though `float('nan') == float('nan')` is `False` — the tuple compares the very same object with itself. Second, because element comparison is delegated to the elements, a heterogeneous pair fails loudly: ```python ('a', 1) < ('a', 'b') # TypeError: '<' not supported between 'int' and 'str' ``` Crucially this is *positional*. The same two tuples compare fine if an earlier position already differs, so a type problem in your data can hide for a long time and then surface on one unlucky pair of records. **Python 3 removed Python 2's fallback ordering between unrelated types**, which is what turned this from a silently arbitrary answer into an exception; the behaviour is unchanged in 3.14. ### Why this makes tuples the multi-field sort key `sorted()` and `list.sort()` take a `key` callable and order the results by the keys' own ordering. Return a tuple from the key and lexicographic comparison gives you multi-field sorting for free: ```python sorted(rows, key=lambda r: (r[0], -r[1])) # first field up, second field down ``` Three techniques follow from that: * **Descending on one field** — negate a numeric field in the key, as `-r[1]` above. `reverse=True` cannot help here because it flips *every* field at once. * **Non-numeric descending** — you cannot negate a string, so sort in two stable passes instead: sort by the secondary field first, then by the primary. Python's sort is guaranteed **stable**, meaning records that compare equal keep their previous relative order, so the second pass preserves the first one's work. * **`operator.itemgetter`** — `key=itemgetter(1, 0)` returns a tuple of the named positions and is usually faster than the equivalent lambda, because the extraction happens in C. The same ordering powers `min()`, `max()` and `heapq`. Pushing `(priority, item)` tuples onto a heap gives a priority queue in one line — and exposes the classic trap: when two priorities tie, the heap falls through to comparing the items themselves, and if those are not orderable you get a `TypeError` at some unpredictable moment under load. The standard fix is a tie-breaker in the middle of the key, such as an always-increasing counter, so no comparison ever reaches the payload. ### Ordering is not equality One asymmetry catches people out. `==` between tuples requires equal lengths and equality at every position, and it never raises for mismatched types — unequal is a perfectly good answer. Ordering has to produce a *direction*, so it must actually compare the differing pair, and that is where `TypeError` comes from. `(1, 'x') == (1, 2)` is simply `False`; `(1, 'x') < (1, 2)` raises. When you only need to know whether two records match, comparing with `==` sidesteps the whole problem. The same rule orders a dict's entries when you sort them, since `dict.items()` yields `(key, value)` pairs: sorting them orders by key first and falls through to the values only on a tie — which quietly raises if the values are unorderable. Passing an explicit key that selects the field you meant, rather than sorting the pairs whole, avoids depending on the fall-through at all. ### Cost and readability Sorting compares keys, not records, and the key function is called exactly once per element — so building a small tuple in the key is cheap even for large inputs. What is *not* cheap is putting expensive work inside the key function, since it runs once per element regardless. For readability, prefer a key that names its fields over one dense expression, and be explicit about direction. A key like `(-total, name)` reads as "biggest total first, ties broken alphabetically", which is precisely the sentence a reviewer wants; two negations and a `reverse=True` in the same call is a bug waiting to happen. ### The interview one-liner Lexicographic means first difference wins, and a prefix is smaller. That single rule explains tuple ordering, multi-field sort keys, the negation trick for descending numeric fields, why a stable sort lets you sort in two passes, and why heap tie-breaks blow up on unorderable payloads.