A metrics scraper sorts @dataclass(order=True) records; why can inserting a field silently change the sort?

seniorshould knowfreq 40%

answer

The sort key is not written anywhere
Comparison walks the fields left to right
Annotations are compared like a tuple
Moving a line changes every comparison
Pin real orderings with an explicit key=

basics

~20 s

order=True generates lt, le, gt and ge that compare instances as tuples of their fields in declaration order. Inserting a field high in the class body silently rewrites the sort key, so sorted() output changes with no call-site edit.

solid answer

~40 s

@dataclass(order=True) generates the four ordering dunders, and each one builds a tuple of the instance's comparison fields in the order the annotations were written and compares those tuples. The sort key is therefore the class body's layout, not an explicit decision, and it is invisible at the call site — sorted(records) reads the same before and after. Add a field near the top during a routine change and every comparison now sorts by that field first; over a three-week release train nobody links the reordered dashboard to the annotation that moved. The fix is to stop relying on implicit ordering for anything that matters: sort with an explicit key= (sorted(rows, key=lambda r: (r.value, r.name))), or keep the sort key as the deliberately-first field and cover it with a test that pins the expected order.

`@dataclass(order=True)` generates the four ordering dunders, and each one builds a tuple of the instance's comparison fields **in the order the annotations were written** and compares those tuples. The sort key is therefore the class body's layout, not an explicit decision, and it is invisible at the call site — `sorted(records)` reads the same before and after. Add a field near the top during a routine change and every comparison now sorts by that field first; over a three-week release train nobody links the reordered dashboard to the annotation that moved. The fix is to stop relying on implicit ordering for anything that matters: sort with an explicit `key=` (`sorted(rows, key=lambda r: (r.value, r.name))`), or keep the sort key as the deliberately-first field and cover it with a test that pins the expected order.

code

python · 19 lines

python

from dataclasses import dataclass

@dataclass(order=True)
class Sample:
    metric: str
    value: int

@dataclass(order=True)
class Other:
    metric: str
    value: int

rows = [Sample("cpu", 10), Sample("cpu", 9), Sample("mem", 1)]
print(sorted(rows))

try:
    Sample("cpu", 1) < Other("cpu", 1)
except TypeError as exc:
    print("cross-class:", exc)

go deeper

for a junior

Know that order=True is what makes dataclass instances sortable at all, and that the comparison uses the fields in the order they were declared in the class body.

for a middle

Explain that the generated methods compare tuples of fields lexicographically, that eq must stay true, and that comparing two different dataclass types raises TypeError rather than comparing structurally.

for a senior

Demonstrate the maintenance argument: an implicit sort key derived from annotation position changes silently under refactoring. Name the guards — an explicit key= at the call site, or a test that pins the expected order.

for a principal

Own the convention: decide as a team which record types treat field order as API, document it where the class is defined, and keep user-visible ordering in explicit sort keys rather than in a decorator flag.

What order=True actually generates

order=True makes @dataclass add __lt__, __le__, __gt__ and __ge__. Each generated method does the same thing: build a tuple of the instance's comparison fields, build the same tuple for the other operand, and delegate to the tuple's own comparison. Tuple comparison is lexicographic — compare the first elements, and only if they are equal move on to the second — so the class becomes ordered by its first annotated field, then the second, and so on.

That is a genuine convenience for records whose declaration order is the intended ranking, and it is a trap for records where it merely happens to line up.

The failure, concretely

A scraper collects metric samples into a record type and the reporting job does sorted(samples) to rank them. The class was written as (metric, value), so the report reads alphabetically by metric name, then by value — which is what the dashboard was built around. Three weeks later someone adds a source field for multi-host scraping and, reasonably, puts it at the top of the class body next to the other identity fields.

Nothing at the call site changed. No signature changed. No test that constructs records by keyword broke. But the sort key is now (source, metric, value), and the report silently regroups by host. Because the change rides a release train with a dozen other changes, the ordering assumption that lived only in the class body is expensive to trace back.

The general shape of the defect: order=True turns an editing decision — where a line goes in a class body — into behaviour, with no syntactic marker at the point where the behaviour is consumed.

The rules around it

A few mechanics are worth having ready:

eq must be true. @dataclass(order=True, eq=False) raises ValueError: eq must be true if order is true at class-creation time. Ordering builds on the same field tuple that equality uses.
Comparison is same-class only. The generated methods return NotImplemented when the other operand is not an instance of the same class, so comparing two structurally identical dataclasses raises TypeError: '<' not supported between instances of 'Sample' and 'Other'. Structural similarity buys nothing.
You cannot hand-write one of them. If the class body already defines __lt__, the decorator raises TypeError: Cannot overwrite attribute __lt__ in class A, and the message itself points you at functools.total_ordering — the alternative when you want a custom rule and the other three derived from it.
Fields excluded from comparison are excluded from ordering as well as from equality, so it is possible to keep a field out of the sort key without moving it.

Making the ordering explicit

There are three sound positions, and picking one deliberately is what a senior answer looks like.

1. Do not use order=True at all. Sort at the point of use with an explicit key: sorted(rows, key=lambda r: (r.value, r.metric)), or operator.attrgetter("value", "metric"). The sort key is now visible in the code that depends on it, and moving an annotation cannot change it. This is the right default for reports, rankings and anything user-visible.

2. Use order=True and treat field order as API. Legitimate when the type genuinely has one natural ordering — a version triple, a timestamped event, a priority record. Then say so: a comment at the top of the class body, a test that asserts the expected sort of a fixed sample list, and a review habit of appending new fields rather than inserting them. The pinned-order test is what actually catches the insertion, because it fails on the commit that moves the line.

3. Keep the sort key first on purpose. For a priority-queue-style record, declare the sort key as the first field and keep the payload behind a field excluded from comparison — the classic "priority, then payload the heap must never compare" shape, which also avoids TypeError when two priorities tie and the payload is not orderable.

The interview point

The question is not "do you know what order=True does" — it is whether you recognise implicit, position-derived behaviour as a maintenance hazard, and whether you can name the cheap guard. Generated comparisons are excellent for value types and poor for business ordering, because business ordering has stakeholders and a class body does not.

## What order=True actually generates `order=True` makes `@dataclass` add `__lt__`, `__le__`, `__gt__` and `__ge__`. Each generated method does the same thing: build a tuple of the instance's comparison fields, build the same tuple for the other operand, and delegate to the tuple's own comparison. Tuple comparison is lexicographic — compare the first elements, and only if they are equal move on to the second — so the class becomes ordered by its first annotated field, then the second, and so on. That is a genuine convenience for records whose declaration order *is* the intended ranking, and it is a trap for records where it merely happens to line up. ## The failure, concretely A scraper collects metric samples into a record type and the reporting job does `sorted(samples)` to rank them. The class was written as `(metric, value)`, so the report reads alphabetically by metric name, then by value — which is what the dashboard was built around. Three weeks later someone adds a `source` field for multi-host scraping and, reasonably, puts it at the top of the class body next to the other identity fields. Nothing at the call site changed. No signature changed. No test that constructs records by keyword broke. But the sort key is now `(source, metric, value)`, and the report silently regroups by host. Because the change rides a release train with a dozen other changes, the ordering assumption that lived only in the class body is expensive to trace back. The general shape of the defect: `order=True` turns an *editing decision* — where a line goes in a class body — into *behaviour*, with no syntactic marker at the point where the behaviour is consumed. ## The rules around it A few mechanics are worth having ready: - **`eq` must be true.** `@dataclass(order=True, eq=False)` raises `ValueError: eq must be true if order is true` at class-creation time. Ordering builds on the same field tuple that equality uses. - **Comparison is same-class only.** The generated methods return `NotImplemented` when the other operand is not an instance of the same class, so comparing two structurally identical dataclasses raises `TypeError: '<' not supported between instances of 'Sample' and 'Other'`. Structural similarity buys nothing. - **You cannot hand-write one of them.** If the class body already defines `__lt__`, the decorator raises `TypeError: Cannot overwrite attribute __lt__ in class A`, and the message itself points you at `functools.total_ordering` — the alternative when you want a custom rule and the other three derived from it. - **Fields excluded from comparison are excluded from ordering** as well as from equality, so it is possible to keep a field out of the sort key without moving it. ## Making the ordering explicit There are three sound positions, and picking one deliberately is what a senior answer looks like. **1. Do not use `order=True` at all.** Sort at the point of use with an explicit key: `sorted(rows, key=lambda r: (r.value, r.metric))`, or `operator.attrgetter("value", "metric")`. The sort key is now visible in the code that depends on it, and moving an annotation cannot change it. This is the right default for reports, rankings and anything user-visible. **2. Use `order=True` and treat field order as API.** Legitimate when the type genuinely has one natural ordering — a version triple, a timestamped event, a priority record. Then say so: a comment at the top of the class body, a test that asserts the expected sort of a fixed sample list, and a review habit of appending new fields rather than inserting them. The pinned-order test is what actually catches the insertion, because it fails on the commit that moves the line. **3. Keep the sort key first on purpose.** For a priority-queue-style record, declare the sort key as the first field and keep the payload behind a field excluded from comparison — the classic "priority, then payload the heap must never compare" shape, which also avoids `TypeError` when two priorities tie and the payload is not orderable. ## The interview point The question is not "do you know what `order=True` does" — it is whether you recognise implicit, position-derived behaviour as a maintenance hazard, and whether you can name the cheap guard. Generated comparisons are excellent for value types and poor for business ordering, because business ordering has stakeholders and a class body does not.

What happens when you compare two different dataclasses that both use order=True and have identical fields?
It raises `TypeError`. The generated `__lt__` checks that the other operand is an instance of the same class and returns `NotImplemented` otherwise; with both sides declining, Python reports `'<' not supported between instances of 'Sample' and 'Other'`. Field-for-field similarity is irrelevant — ordering, like the generated equality, is nominal, not structural.
What does @dataclass do if the class body already defines __lt__ and you pass order=True?
It raises `TypeError: Cannot overwrite attribute __lt__` at class-creation time, and the message suggests `functools.total_ordering`. The decorator refuses to silently discard hand-written comparison logic. The usual resolution is to drop `order=True`, write `__eq__` and `__lt__` yourself, and let `functools.total_ordering` fill in the remaining three operators.
Can you pass order=True together with eq=False?
No — it raises `ValueError: eq must be true if order is true` when the class is created. The generated ordering methods compare the same field tuple that the generated `__eq__` uses, so the decorator will not produce a `<` that is inconsistent with an equality it did not write. If you need custom equality plus ordering, write both yourself.

It is like sorting a spreadsheet by whichever column happens to be leftmost: perfectly predictable until someone inserts a column, and nothing in the sort command records what you meant.

saying these in an interview costs you the question

Thinks order=True sorts by the most meaningful field
Assumes two identical-looking dataclasses compare across classes
Calls reordering annotations a purely cosmetic refactor
Believes order=True works with eq=False
Relies on bare sorted() for user-visible business ordering
Expects the decorator to override a hand-written __lt__

A metrics scraper sorts @dataclass(order=True) records; why can inserting a field silently change the sort?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What order=True actually generates

The failure, concretely

The rules around it

Making the ordering explicit

The interview point

▾common follow-ups3 questions

▾analogy~10 s

▾red flags6 flags

§ context

▾related questions4 questions

▾related topics4 topics

What order=True actually generates

The failure, concretely

The rules around it

Making the ordering explicit

The interview point

answer

go deeper

context