Why does Python randomize str hashes per process, and when do you set PYTHONHASHSEED?

### What is randomized, and why Since **3.3**, CPython seeds the hash function for `str`, `bytes` and `datetime` objects with a random value chosen at interpreter startup. `hash("scrape_ok")` therefore returns a different integer in every new process. `sys.hash_info.algorithm` reports the algorithm (`siphash13` on a stock 3.14 build) and `sys.flags.hash_randomization` reports whether the seeding is active. The motivation is a denial-of-service class, not cryptography. Dict and set operations are O(1) *on average*, and degrade toward O(n) per operation when many keys land in the same region. An attacker who controls a lot of key strings — form field names, JSON object keys, HTTP header names, metric label names scraped from a remote target — could precompute thousands of strings that collide under a fixed hash function and turn one request into quadratic work. Randomizing the seed per process makes that precomputation impossible: the adversary cannot know this process's hash mapping. **Numbers are not randomized.** `hash(42) == 42` in every process, and the numeric hash invariant described by `sys.hash_info` is fixed. Only the string-like and datetime hashes move. ### The consequences you actually live with **Sets and set-derived orderings vary between runs.** Dicts have iterated in insertion order since **3.7**, so dict iteration is *not* affected — this is the nuance that separates a real answer from a memorized one. But `list({"cpu", "mem", "disk"})` genuinely differs run to run, and so does anything built from it: a rendered golden file, a comparison of `set` output, an "any element" pick. The classic symptom is a test that fails on roughly one CI run in five with no code change. **`hash()` is an in-process value with no persistence guarantee.** It is not stable across restarts, across processes, across interpreter versions or across builds. Writing it into a cache filename, a sharding column, a bloom filter on disk, or a partition key is a latent outage. Concretely: a metrics scraper distributes series across worker processes with `hash(series_name) % worker_count`. It looks correct in a single-process test and even survives a restart of the whole fleet, because everything is recomputed at once. Then one worker restarts on its own, computes a different mapping, and starts scraping series that another worker still owns — duplicate samples for some series, gaps for others, and a cache hit-rate collapse that shows up as a breach of the 92nd-percentile scrape-latency budget. The bug is not in the sharding math; it is in using a per-process value as if it were stable. ### `PYTHONHASHSEED` `PYTHONHASHSEED` is read **at interpreter startup**, so setting `os.environ["PYTHONHASHSEED"]` inside a running process does nothing — it must be in the environment of the command that launches Python. Its values: - `random` — the default: pick a fresh seed per process. - an integer in `[0, 4294967295]` — use that seed, making string hashes and therefore set ordering reproducible across runs. - `0` — disable randomization entirely. Legitimate uses are all about **reproducibility**: pinning a seed in CI to reproduce an order-dependent test failure, bisecting a flaky ordering bug, or producing a byte-identical build artefact. Pinning it permanently for a service that hashes untrusted input re-opens the collision DoS the feature exists to prevent — and, more mundanely, it hides an ordering bug rather than fixing it. The real fix for an order-dependent test is to sort the output or compare sets, not to freeze the seed. ### Child processes Seeding happens per interpreter, so the start method decides what a worker sees. A `fork` child inherits the parent's memory and therefore the parent's seed; `spawn` and `forkserver` start a fresh interpreter that seeds itself, so `hash("x")` differs between parent and child. That matters more on **3.14**, where the default `multiprocessing` start method on Unix other than macOS became `forkserver` (macOS and Windows remain `spawn`, and `fork` must now be requested explicitly). Code that quietly relied on parent and child agreeing on `hash()` under `fork` will start misbehaving on the new default. ### What to use instead Anything that must survive a process boundary needs a documented, stable digest: `hashlib.blake2b(name.encode(), digest_size=8)` or `hashlib.sha256` for correctness-critical or adversarial contexts, or a small non-cryptographic algorithm you own and version. Reserve `hash()` for what it is: an in-memory implementation detail of `dict` and `set`, valid for exactly as long as the process that produced it.