Can you rely on the iteration order of a Python set or frozenset?

### There is no order to rely on A `set` and a `frozenset` are hash tables with no auxiliary ordering structure. They implement no `__getitem__`, so `fs[0]` raises `TypeError: 'frozenset' object is not subscriptable`, and there is no `.first()`, no slicing and no reverse iteration. Iterating one walks the internal table from slot zero upward and yields whatever is parked in each occupied slot. That order is a function of three things: the hash of each element, the current table size (which grows in powers of two as the set fills), and the history of insertions and deletions that produced the current layout. None of those are part of the language contract. Two sets that compare equal can iterate in different orders — build `{1, 2, 3}` by adding in one sequence and another by adding in the reverse, and after enough resizes their layouts can differ while `==` still reports `True`. ### The part that surprises people: it varies between runs For `int` elements, CPython hashes a small integer to itself, so the layout is reproducible run after run. For `str` and `bytes`, it is not. CPython salts string hashing with a per-process random seed, so the same script can print different orders on consecutive runs: ```console $ python3.14 -c "print(list({'alpha', 'beta', 'gamma', 'delta'}))" ['alpha', 'gamma', 'beta', 'delta'] $ python3.14 -c "print(list({'alpha', 'beta', 'gamma', 'delta'}))" ['delta', 'beta', 'alpha', 'gamma'] ``` This is deliberate. Without a salt, an attacker who controls the string keys reaching a hash table can craft a set of inputs that all collide into one bucket, degrading lookups from near-constant to linear and turning a modest request into a denial of service. Randomizing the seed makes those collision sets unpredictable per process. The price is that string-keyed hash layout is not stable across processes. Setting the `PYTHONHASHSEED` environment variable to a fixed integer disables the randomization and makes the order repeatable. That is a legitimate debugging move — pin the seed, reproduce the odd ordering, understand the bug — and a poor production setting, because you are trading a security property for a convenience you should not have been depending on in the first place. ### What breaks when you depend on it The failures all have the same shape: something passes locally and fails elsewhere, or passes a thousand times and fails once. * A test asserting `list(result_set) == ['a', 'b', 'c']` passes on your machine and fails in CI. * A log line or an error message that lists a set renders its items in a different order every restart, so diffing two runs is useless. * A serialized payload built from a set produces a different byte string per process, breaking any downstream checksum, cache key or golden-file comparison. * A "pick one" step written as `next(iter(candidates))` chooses a different candidate per process, which is fine until the choice is user-visible or must be reproducible. ### Doing it properly If order matters, impose it explicitly at the point of use. `sorted(fs)` returns a **list** in an order you defined — note that it is not a set, and that it costs O(n log n) each time. `min(fs)` or `max(fs)` gets a deterministic single element without a full sort. If the order is intrinsic to the data rather than to the presentation, the set is the wrong structure: keep an ordered container and use a set only as a companion membership index. `next(iter(fs))` is the right way to grab *an* element when genuinely any member will do — it is cheap and honest about being arbitrary. It is the wrong way the moment a log, a test or a response body records which one was chosen. ### One contrast worth stating explicitly `dict` and `set` are both hash tables, and people carry a rule from one to the other that does not apply. Dicts have a documented insertion-order guarantee; sets have never had one and still do not on 3.14. The randomization itself is not new either — it has been on by default since 3.3. If your mental model is "Python containers remember order now", sets are the exception that will eventually cost you an afternoon.