Why does `3 < 'apple'` raise TypeError in Python 3 when Python 2 ordered them?

### What the interpreter actually does `3 < 'apple'` is a binary operation, and Python resolves every binary operation the same way: it asks each operand, in turn, whether it knows how to handle the other. For `<` the interpreter first calls the left operand's less-than method, `int.__lt__(3, 'apple')`. `int` has no idea how to order itself against text, so instead of guessing it returns the singleton `NotImplemented` — a sentinel that means "not my job", not "the answer is false". Python then tries the **reflected** operation: `a < b` is answered by `b > a`, so it calls `str.__gt__('apple', 3)`. `str` also returns `NotImplemented`. Both operands have now declined, no fallback ordering exists, and the interpreter raises `TypeError: '<' not supported between instances of 'int' and 'str'`. The six rich comparison methods pair up like this: `__lt__` reflects to `__gt__`, `__le__` reflects to `__ge__`, and `__eq__`/`__ne__` reflect to themselves. There is one wrinkle in the order of the two attempts: if the right operand's type is a proper subclass of the left operand's type and overrides the reflected method, Python gives the subclass the first try, so a subclass can always override its parent's ordering. ### Why Python 2 answered instead of raising Python 2 had two mechanisms Python 3 deleted. The first was a single three-way comparison hook — one method returning a negative number, zero or a positive number, the C-style `strcmp` shape — which the six rich comparison methods replaced. The second, and the one that produced the surprising answers, was a **default total ordering across unrelated types**: when neither operand knew what to do, Python 2 fell back to an arbitrary but internally consistent rule (numbers sorted before everything else, and remaining types were ordered by type name). So `3 < 'apple'` was `True`, and `sorted([1, 'a', None])` returned a list that was "sorted" in a way no reader could predict or depend on. It was consistent within one run, but meaningless — and it silently hid data bugs, which is exactly why Python 3.0 removed it. Since 3.0 the rule has not changed, and it is the same on 3.14. ### Ordering fails loudly, equality does not `3 == 'apple'` does **not** raise; it returns `False`. The dispatch is identical — both `__eq__` implementations return `NotImplemented` — but equality has a sensible last resort that ordering does not: two objects that cannot compare themselves are simply not the same object, so Python falls back to identity and answers `False`. There is no comparable last resort for `<`. This asymmetry is worth carrying into an interview because it explains a common surprise: a dictionary lookup or an `in` test over a mixed list works fine, while sorting the same list explodes. ### Where this bites in production Sorting is the usual trigger, because `sorted()`, `min()`, `max()` and `list.sort()` are built entirely out of `<`. In a log-ingest pipeline whose events arrive as loosely typed records, a field that is normally an integer occasionally arrives as a string — a hand-edited config, a producer that serialized an ID as text, an unparsed `null` that lands as `None`. Nothing fails on ingest. The failure appears only in the batch that happens to contain both shapes, and only once the sort reaches the pair that cannot be compared, so a job that spends 45 seconds warming up and reading input dies deep in the run with a message about types the caller never knowingly mixed. Note also that the exception can arrive partway through: `sorted()` builds a new list so your input is untouched, but `list.sort()` may leave the list in an unspecified order after raising. `None` is the single most common offender, because `None` supports no ordering at all — `None < 1` raises for exactly the same reason `'apple' < 1` does. ### What to do about it Normalize at the boundary. Decide what the field is, coerce or reject on the way in, and sort a homogeneous sequence — that is a data-quality fix, not a comparison fix. If mixed values are genuinely legitimate, define the ordering explicitly by mapping every element to one comparable shape before sorting, so the ordering is a decision you wrote down rather than an accident of the interpreter. Never "fix" it by wrapping the sort in a `try`/`except TypeError`: that hides the malformed record instead of surfacing it. The same dispatch governs your own classes: when an instance of your type is compared with something it does not understand, it should hand the decision back with `NotImplemented` so the other operand gets its turn and, if nobody can answer, Python raises the standard, well-worded `TypeError` on your behalf. And `functools.total_ordering` is only a convenience on top of this machinery — it fills in the missing ordering methods from one you wrote, but it cannot invent an ordering between types that have none.