How do you make sorted() order one field descending and another ascending?

### Why `reverse=` alone cannot do it `sorted()`'s `reverse` argument is a single boolean that flips the **entire** ordering. There is no per-field version of it, and no way to pass a direction per component of a tuple key. So "confidence descending, place name ascending" needs one of two techniques. ### Technique 1 — negate the numeric component of a tuple key A tuple key compares element by element, so `(-score, name)` sorts by `-score` ascending — which is score descending — and breaks ties by name ascending: ```python rows = [("Springfield", 0.92), ("Ashland", 0.92), ("Bristol", 0.75)] sorted(rows, key=lambda r: (-r[1], r[0])) # [('Ashland', 0.92), ('Springfield', 0.92), ('Bristol', 0.75)] ``` One pass, one key call per element, easy to read. Its limit is exactly the word *numeric*: you can negate an `int`, a `float`, a `Decimal` or a `Fraction`, but there is no negation of a `str`, a `datetime`, a `date`, a `tuple`, or of `None`. A date can be pushed through the trick by converting it to a numeric timestamp first; a string cannot be, and candidates who try to invent one (reversing the characters, subtracting ordinals) produce something that is wrong for anything but fixed-length ASCII. ### Technique 2 — two stable passes, least significant field first Python's sort is **guaranteed stable**: elements that compare equal keep their original relative order. That guarantee is documented and has held since Python 2.2, and it is unchanged through 3.14. Stability turns a multi-field ordering into a sequence of single-field sorts, provided you run them from the **least** significant field to the **most** significant: ```python rows = sorted(rows, key=lambda r: r[0]) # secondary: name ascending rows = sorted(rows, key=lambda r: r[1], reverse=True) # primary: score descending ``` The second pass reorders by score; among records with the same score it changes nothing, so the name ordering established by the first pass survives. This composes to any number of fields with any mix of directions, and it is the general answer — the tuple trick is the special case that happens to be shorter when every descending field is a number. The cost is real: k passes are k sorts, so 2x the comparison work here, plus a fresh list per pass. For a few hundred thousand rows that is usually irrelevant next to readability; for a hot path, prefer the single tuple key when the types allow it. ### The subtlety that separates a senior answer: `reverse=True` is not `reversed()` `sorted(data, key=f, reverse=True)` is **not** the same as reversing an ascending sort. `reverse=True` is defined to preserve the original relative order of equal elements — stability holds in the descending direction too — whereas `reversed(sorted(...))` flips ties along with everything else. ```python rows = [("Springfield", 0.92), ("Ashland", 0.92), ("Bristol", 0.75)] sorted(rows, key=lambda r: r[1], reverse=True) # [('Springfield', 0.92), ('Ashland', 0.92), ('Bristol', 0.75)] list(reversed(sorted(rows, key=lambda r: r[1]))) # [('Ashland', 0.92), ('Springfield', 0.92), ('Bristol', 0.75)] ``` This is where the multi-pass technique silently breaks if you reach for `reversed()`: the flip destroys the tie order the earlier pass established, and every field you had already ordered is scrambled within each tie group. It also matters at a cutoff. Rank a geocoding batch by confidence and keep the candidates above a 92nd-percentile threshold: if several candidates sit exactly on the boundary value, which ones land inside a `[:k]` slice is decided entirely by tie order. Swap `reverse=True` for a `reversed()` call, or reorder the passes, and the slice takes a different record at the boundary — a one-record off-by-one that is invisible in tests with distinct scores and shows up only on real data where ties are common. The fix is to make the ordering total: add an explicit, unique tie-breaker (a stable identifier) as the last component of the key, so the result does not depend on input order at all. ### How to answer it Say the three things in order: `reverse=` is all-or-nothing; a tuple key with a negated numeric component handles the common case in one pass; stability plus least-significant-first passes handles the general case, including descending on a non-numeric field. Then volunteer that ties at a cutoff deserve an explicit tie-breaker rather than reliance on stability, and you have answered the follow-up before it is asked.