Why do 1, 1.0 and True collapse into a single dict key in Python?

### One equality class, one key Python's dict does not group keys by type. It groups them by **equality**, and the hash exists only to find candidates quickly. The invariant that makes that work is: if `x == y`, then `hash(x) == hash(y)`. Python's numeric tower deliberately makes numbers of different types compare equal when their mathematical values match, so the hash invariant forces them to share a slot: ```pycon >>> 1 == 1.0 == True True >>> hash(1), hash(1.0), hash(True) (1, 1, 1) ``` `bool` is a subclass of `int`, with `True` equal to `1` and `False` equal to `0`. `decimal.Decimal("1")` and `fractions.Fraction(1, 1)` join the same club. So a dict or set can hold **one** entry for that whole family, and `d[True]`, `d[1]` and `d[1.0]` are three spellings of one lookup. The float side is not a coincidence of small values. CPython hashes a rational number by mapping it into modular arithmetic with `sys.hash_info.modulus` (2**61 - 1 on a 64-bit build), which is why `hash(0.5) == hash(Fraction(1, 2))` as well. Any two numeric objects that are `==` hash the same, by construction. ### The lookup path, and which key object survives A lookup computes the hash, picks a slot, and for each candidate does an identity check (`is`) first and `==` second. The identity shortcut is a fast path — and the reason a `float('nan')` key can be retrieved with the *same* object even though `float('nan') != float('nan')`. The detail people get wrong: on assignment to an **existing** key, a dict replaces the *value* and keeps the *key object it already stored*. So insertion order decides the key's type: ```pycon >>> samples = {1.0: "a"} >>> samples[1] = "b" >>> samples {1.0: 'b'} ``` The dict now maps a `float` key to the value written through an `int`. `dict.update()`, `|=` and `setdefault()` behave identically. The same holds for sets: `{1, 1.0, True}` is `{1}`, retaining the first element inserted. ### How this bites in real code Take a metrics scraper that parses sample values out of text and keeps a per-value tally. The text arrives in a locale-dependent number format, so one collector's parser yields the `int` `1` and another's yields the `float` `1.0` for the very same reading. Two things happen at once and neither raises: 1. The two tallies **merge** into a single entry, so a count you expected to be split is doubled. 2. Which one merged into which depends on arrival order, so the key serializes as `1` on one run and `1.0` on the next — a dashboard label or a JSON payload flips shape with no code change. The same collision shows up with flag-shaped keys: a mapping written as `{0: "off", False: "disabled"}` has one entry, and `{1: "on", True: "enabled"}` likewise. The fix is not to fight the dict; it is to **normalize at the parse boundary**. Decide one canonical key type — a `str`, a `Decimal`, or a plain `int` — and convert as data enters. When the *type* is genuinely part of the identity, make it part of the key: `(type(value).__name__, value)` or an explicit enum tag. And use enum members or strings rather than `True`/`False` for dict keys whenever `0` or `1` might also appear. ### NaN, and one curiosity `float('nan')` is hashable and can be stored, but since it is not equal to itself, only the exact object you inserted will find the entry — a freshly built NaN never matches. Since **3.10**, distinct NaN objects hash by object identity rather than all hashing to `0`; before that, a dict holding many NaN keys degraded toward a linear scan because they all landed in one slot. And a favourite piece of trivia: `hash(-1)` is `-2`. `-1` is the error sentinel in CPython's C-level hash API, so the integer `-1` reports `-2` instead — which means `-1` and `-2` share a hash. They are still two separate keys, because they are not equal: hash collisions are normal and harmless; equality is what decides identity of a key. ### What the interviewer is testing Not the trivia. They want to hear that a dict is a mapping over equality classes, that the hash invariant is the mechanism, that the first-inserted key object is the one kept, and that the practical defence is normalizing key types at the boundary rather than hoping values stay in one lane.