Why use a frozenset rather than a sorted tuple as a cache key for tags?

### The question a cache key answers A cache key is a claim about identity: *these two inputs are the same input, so they may share an answer.* Pick the wrong key and you do not get an error, you get a confidently wrong cached result. So the choice between `frozenset(tags)` and `tuple(sorted(tags))` is a semantic decision before it is a performance one. Concretely: a ticket-triage bot decides a route for each incoming ticket from its tag collection, and the decision is expensive enough that the service caches it to keep the 92nd-percentile response inside its latency budget. Both candidate keys are hashable and both work. They disagree about which tickets share an entry. ### What each key means `frozenset(tags)` says *these tags, in any order, ignoring repeats*. `frozenset(["billing", "billing", "urgent"])` equals `frozenset(["urgent", "billing"])`, so both tickets hit the same entry. It requires only that the elements be hashable, which strings and integers always are. `tuple(sorted(tags))` says *these tags with their multiplicities, canonicalized by sorting*. `("billing", "urgent", "urgent")` and `("billing", "urgent")` are different keys. It also requires the elements be mutually **comparable**, which is a stricter demand than hashable: a tag collection that mixes `str` and `int` raises `TypeError: '<' not supported between instances of 'int' and 'str'` at key-construction time — a failure the frozenset key would never have produced. So: if duplicate tags are meaningless noise, a frozenset key raises your hit rate for free. If a repeated tag carries meaning — a weight, a count, a repeated escalation — the frozenset key silently merges inputs that should not share an answer, and the sorted tuple is correct. ### Wiring it up ```python from functools import lru_cache @lru_cache(maxsize=1024) def route(tags): return "finance-queue" if "billing" in tags else "general-queue" print(route(frozenset(["billing", "billing", "urgent"]))) print(route(frozenset(["urgent", "billing"]))) # cache hit: same key ``` `functools.lru_cache` hashes its arguments to build its own key, so every argument must be hashable — the same constraint a dict key faces, arriving through a different door. Hand it a plain `set` and it raises `TypeError: unhashable type: 'set'`. ### The failure that actually shows up in review The most common way a raw `set` reaches a cache is a mutable default: ```python def route(ticket, tags=set()): # bug ... ``` That default object is created once, when the `def` statement executes, and is shared by every call that omits the argument. It is mutable, so one call's additions leak into the next; and it is unhashable, so the moment it reaches the cache the request fails. Both problems disappear with the same fix: default to `None` and normalize at the top of the function. ```python def route(ticket, tags=None): key = frozenset(tags or ()) ... ``` Converting at the boundary is the whole discipline. Callers keep working with the ergonomic mutable collection; the function immediately takes a frozen snapshot, so later mutation by the caller cannot reach the key or the entry it indexes. ### Keys that look tempting and are not `str(tags)` is the classic wrong answer. It appears to work, and it is wrong twice over: the repr of a set embeds the set's iteration order, which for string elements varies per process, so the same tags produce different keys in different workers; and the string is not injective, so distinct inputs can collide. `id(tags)` is worse, keying on object identity that is reused after garbage collection. If the elements themselves are unhashable — tag objects, dicts of attributes — no built-in conversion saves you. Project each element down to a hashable canonical form first, and be honest that the cache is then keyed on the projection rather than on the original objects. ### One thing the frozen key does not buy Freezing the key protects the index, not the value. If the cached result is a mutable object handed back to every caller, one caller's edit corrupts every subsequent hit. In a shared cache, return an immutable value or a copy — the discipline that makes the key trustworthy has to extend to the other side of the entry.