Why does hash('abc') differ between two Python processes, and what does PYTHONHASHSEED=0 cost?

## What randomization is defending A dict or a set places a key by its hash. When many distinct keys share a hash, the container has to fall back on comparing them, and the cost of inserting n such keys grows quadratically rather than linearly. That is fine as an accident and dangerous as a choice: if the hash function is fixed and public, an attacker can compute a large set of distinct strings that all collide and send them as the keys of one request — object keys in a JSON body, fields in a form, header names, query parameters. The receiving service does no more work than "parse a request into a dict", and that request costs seconds of CPU instead of microseconds. The defence is to make the function unpredictable per process. CPython draws a random seed at interpreter startup and mixes it into the hash of text-like objects. An attacker can still cause collisions inside a *single* known process if they can observe hashes, but they cannot precompute a payload that works against a process they have never seen, which is what makes the attack cheap. This has been the default since Python 3.3. The algorithm is pluggable — `sys.hash_info` reports which one the build uses — and the default has been SipHash since 3.4, with SipHash-1-3 replacing SipHash-2-4 in 3.11 for speed. Note the goal: it is a *keyed* hash for collision resistance against an adversary who cannot see the key. It is not a cryptographic digest, and `hash()` must never be used where you want one; that is what `hashlib` is for. ## What is randomized, and what is not Randomized: `str`, `bytes`, and by extension every object whose hash is derived from them — a tuple of strings, a frozenset of strings, a `datetime` value. Not randomized: numbers. `hash(1234) == 1234`, and small floats hash to the same value as the equal int. This is required by the language's own rule that objects comparing equal must hash equal, so that `1`, `1.0` and `True` interchange as dict keys. The security consequence is worth saying out loud: **if your attacker-controlled keys are integers, hash randomization gives you nothing**, and the bound has to come from limiting how many keys you accept in the first place. That last point generalizes. Randomization raises the cost of one specific attack; it is not a substitute for a cap on the number of fields, keys or headers a request may carry. ## What it costs you Because the seed changes every run, `hash()` is only meaningful inside one process's lifetime. Three rules follow: - **Never persist a `hash()` value.** Not as a cache key in a shared store, not as a column, not in a file. It will not match tomorrow. Use `hashlib.sha256` and take a digest if you need a stable fingerprint. - **Never shard on `hash()` across processes.** `hash(key) % n` routes differently in each worker, because each worker drew its own seed at startup. - **Set iteration order varies between runs.** Dict iteration has been insertion-ordered since 3.7, so dicts look stable; sets do not, and that is where the flakiness lands. ``` $ python3 -c 'print(list({"a", "b", "c", "d", "e"}))' ['c', 'b', 'd', 'a', 'e'] $ python3 -c 'print(list({"a", "b", "c", "d", "e"}))' ['d', 'b', 'e', 'a', 'c'] ``` ## The trap worth naming A CSV import for a payroll system has one test that asserts on the order of a set of validation messages. It fails about one run in five. The 27-minute suite is already the slowest thing in the pipeline, so nobody wants to re-run it, and someone finds that `PYTHONHASHSEED=0` makes the ordering stable. It goes into the CI configuration, the fix works, the flake stops. Then that environment block is copied — as environment blocks always are — into the deployment manifest, and production now runs every worker with a known, fixed hash function. Nothing breaks. No test fails. The collision-flood defence is simply gone, and the only evidence is one line in a YAML file that reads like a test setting. The fix for the flaky test was never the seed. Sort the messages, or compare sets to sets rather than lists to lists. If you genuinely need determinism to reproduce one confusing failure, set the variable for that single command, not for the pipeline and never for an image that also ships to production. Two mechanical details. `PYTHONHASHSEED` is read when the interpreter starts, so assigning `os.environ["PYTHONHASHSEED"]` inside a running program does nothing to that program; it affects only children you launch afterwards. And the seed is per interpreter process — separately started workers do not share one, so anything that requires several processes to agree on a hash must use an explicit stable function rather than the built-in. ## Reviewing for it Three questions cover almost all of it. Does any stored value or cross-process decision come from `hash()`? Does any test depend on set iteration order? And is `PYTHONHASHSEED` set anywhere outside a developer's own shell? A "yes" to the third is worth a conversation every time.