{"title":"Frozen Sets","description":"","content":"`frozenset` is the immutable, hashable cousin of `set`. It supports every read-only set operation you already know (membership, union, intersection, subset checks) but rejects anything that would mutate it. Because it can't change, Python can hash it, which means a `frozenset` can be used as a dictionary key or stored inside another set. This lesson covers when that matters and how to use it well.\n\n---\n\n# What `frozenset` Is and Why It Exists\n\nA regular `set` is mutable. You can `add`, `remove`, `discard`, `pop`, and `clear` its elements, and you can update it in place with operators like `|=`. That mutability is convenient, but it has one big downside: a `set` is unhashable. Python can't use a mutable object as a dictionary key or as a member of another set, because its hash would change every time you mutated it, and the surrounding data structure would lose track of where it lived.\n\n\n```python\ntags = {\"electronics\", \"sale\"}\n\n# Try to use a set as a dict key.\ndiscounts = {tags: 0.10}\n```\n\n\nThat error is the whole reason `frozenset` exists. A `frozenset` holds the same kind of unordered, unique elements that a `set` holds, but it's immutable. Once you've built one, you can't add to it, remove from it, or otherwise change its contents. Because it doesn't change, Python can give it a stable hash, so it works anywhere hashability is required.\n\n\n```python\ntags = frozenset({\"electronics\", \"sale\"})\n\ndiscounts = {tags: 0.10}\nprint(discounts)\n```\n\n\nSame elements, but the wrapping type is now `frozenset`, and Python is happy to use it as a key.\n\n\n> **INFO**\n>\n> **Cost:** `frozenset` has the same average O(1) lookup and membership cost as `set`. Immutability is what you're paying for, not raw speed. Building a `frozenset` from an iterable is O(n), the same as building a `set`.\n\n\n---\n\n# Creating a frozenset\n\n`frozenset` is a built-in type, just like `set`. The constructor takes any iterable and returns a frozen copy of its unique elements.\n\n\n```python\n# From a list of strings.\npermissions = frozenset([\"read\", \"write\", \"read\"])\nprint(permissions)\n\n# From another set.\ntags = frozenset({\"electronics\", \"sale\", \"new\"})\nprint(tags)\n\n# Empty frozenset.\nempty = frozenset()\nprint(empty)\n\n# From a string (each character becomes an element).\nletters = frozenset(\"orders\")\nprint(letters)\n```\n\n\nDuplicates are dropped during construction, exactly like a regular `set`. The order in the `repr` is hash-driven and shouldn't be relied on.\n\nOne thing to keep in mind: there is no literal syntax for `frozenset`. You can write `{1, 2, 3}` for a `set` and `{\"a\": 1}` for a `dict`, but there's no equivalent for `frozenset`. You always go through the constructor.\n\n\n```python\n# This is a set literal, not a frozenset.\nordinary = {1, 2, 3}\nprint(type(ordinary))\n\n# This is the only way to build a frozenset.\nfrozen = frozenset({1, 2, 3})\nprint(type(frozen))\n```\n\n\n`{}` always builds a dict (the empty dict literal). `set()` builds an empty set. `frozenset()` builds an empty frozenset. No surprises once you know the rule, but new readers sometimes expect a literal that doesn't exist.\n\n---\n\n# What Works (Read-Only Operations)\n\nEvery read-only set operation works the same way on a `frozenset`. Membership checks, length, iteration, union, intersection, difference, symmetric difference, subset and superset checks, and `isdisjoint` are all available. The mechanics are identical to the mutable `set` versions.\n\n\n```python\nviewed = frozenset([\"mouse\", \"cable\", \"webcam\"])\npurchased = frozenset([\"cable\", \"keyboard\"])\n\n# Membership and size.\nprint(\"mouse\" in viewed)\nprint(len(viewed))\n\n# Iteration.\nfor product in sorted(viewed):\n print(product)\n\n# Combining frozensets.\nprint(viewed | purchased)\nprint(viewed & purchased)\nprint(viewed - purchased)\nprint(viewed ^ purchased)\n\n# Relationship checks.\nprint(frozenset([\"cable\"]).issubset(viewed))\nprint(viewed.isdisjoint(frozenset([\"keyboard\"])))\n```\n\n\nOperator results between two frozensets are themselves frozensets. The method forms (`viewed.union(purchased)`, `viewed.intersection(purchased)`, etc.) also return frozensets when called on a frozenset. That keeps the immutability promise: you can chain set algebra without ever creating a mutable result by accident.\n\nThe read-only half of the set API carries over to `frozenset` without changes.\n\n---\n\n# What Doesn't Work (Mutation)\n\nAnything that would modify the frozenset is gone. The methods aren't defined on the type at all, and in-place operators raise type errors.\n\n\n```python\npermissions = frozenset([\"read\", \"write\"])\npermissions.add(\"delete\")\n```\n\n\nThe error is `AttributeError`, not `TypeError`, because the method literally doesn't exist on `frozenset`. The same is true for `remove`, `discard`, `pop`, `clear`, and `update` (along with `intersection_update`, `difference_update`, and `symmetric_difference_update`).\n\n\n```python\npermissions = frozenset([\"read\", \"write\"])\n\nfor method in [\"remove\", \"discard\", \"pop\", \"clear\", \"update\"]:\n print(method, hasattr(permissions, method))\n```\n\n\nThe in-place operators behave a little differently. They exist on `frozenset` in the sense that Python will try them, but they raise `TypeError` because there's no way to mutate a frozenset.\n\n\n```python\npermissions = frozenset([\"read\", \"write\"])\npermissions |= frozenset([\"delete\"])\n```\n\n\nIf you genuinely want a \"frozenset with one more element\", you build a new frozenset from the union:\n\n\n```python\npermissions = frozenset([\"read\", \"write\"])\npermissions = permissions | frozenset([\"delete\"])\nprint(permissions)\n```\n\n\nThe name `permissions` now points at a new frozenset. The original object wasn't modified, you just rebound the name. That's a normal Python pattern with immutable values (strings and tuples work the same way).\n\nHere's a quick mental model for what's available and what isn't:\n\n\n```mermaid\nflowchart LR\n OPS[\"Set Operation\"]:::cyan\n\n READ[\"Read-only:
in, len, iter,
union, intersection,
difference, subset,
superset, isdisjoint\"]:::green\n MUT[\"Mutation:
add, remove, discard,
pop, clear, update,
|=, &=, -=, ^=\"]:::red\n\n SOK[\"Works on set
and frozenset\"]:::teal\n FROZE[\"Works on set only
(AttributeError or
TypeError on frozenset)\"]:::orange\n\n OPS --> READ --> SOK\n OPS --> MUT --> FROZE\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe left branch is the half of the set API that carries over unchanged. The right branch is the half that's blocked, either by the method not existing (`AttributeError`) or by the operator refusing to mutate the receiver (`TypeError`).\n\n---\n\n# Hashability and Real Use Cases\n\nThe point of `frozenset` is that it's hashable. Once you have that, three patterns open up that a regular `set` can't support.\n\n### Using a frozenset as a dictionary key\n\nA common case is mapping a group of attributes to some computed value. With a regular set you couldn't do this. With a frozenset, the group itself becomes the key.\n\n\n```python\n# Discount percent for combinations of product tags.\ndiscount_table = {\n frozenset({\"electronics\", \"sale\"}): 0.10,\n frozenset({\"electronics\", \"clearance\"}): 0.25,\n frozenset({\"clothing\", \"sale\"}): 0.15,\n frozenset({\"clothing\", \"clearance\"}): 0.30,\n}\n\ndef discount_for(tags):\n key = frozenset(tags)\n return discount_table.get(key, 0.0)\n\nprint(discount_for([\"sale\", \"electronics\"]))\nprint(discount_for([\"clearance\", \"electronics\"]))\nprint(discount_for([\"new\", \"electronics\"]))\n```\n\n\nThe order of tags doesn't matter at the call site, because the lookup key is a frozenset. `{\"sale\", \"electronics\"}` and `{\"electronics\", \"sale\"}` produce the same key and hit the same entry. That's a property you can't get with a list or tuple key, where order would matter.\n\n### Storing frozensets inside another set\n\nYou can build a set of frozensets, which is the natural way to track \"the distinct combinations of X we've seen\".\n\n\n```python\n# Distinct combinations of tags that customers have actually filtered by.\nseen_filter_combos = set()\n\ncustomer_filters = [\n [\"electronics\", \"sale\"],\n [\"electronics\", \"sale\"], # duplicate combination\n [\"clothing\", \"new\"],\n [\"sale\", \"electronics\"], # same combination as first, different order\n [\"clothing\", \"new\", \"sale\"],\n]\n\nfor filters in customer_filters:\n seen_filter_combos.add(frozenset(filters))\n\nfor combo in seen_filter_combos:\n print(sorted(combo))\n```\n\n\nThree unique combinations from five filter applications. The two `{\"electronics\", \"sale\"}` requests and the `{\"sale\", \"electronics\"}` request all collapse into one entry, because frozensets compare by contents and hash to the same value regardless of insertion order.\n\n\n> **INFO**\n>\n> **Cost:** `frozenset` membership and hashing are both O(1) on average. Building a `set` of frozensets is the same cost as building a `set` of strings or integers: linear in the total number of elements you put in.\n\n\n### Constants and configuration\n\n`frozenset` is the right choice for a fixed lookup table of allowed values. Because it's immutable, you can declare it at module scope and trust that no other code can corrupt it.\n\n\n```python\nVALID_ORDER_STATUSES = frozenset({\n \"placed\",\n \"confirmed\",\n \"shipped\",\n \"delivered\",\n \"cancelled\",\n})\n\nADMIN_PERMISSIONS = frozenset({\n \"read\", \"write\", \"delete\", \"approve\",\n})\n\ndef transition_to(new_status):\n if new_status not in VALID_ORDER_STATUSES:\n raise ValueError(f\"Unknown status: {new_status}\")\n print(\"Transitioned to\", new_status)\n\ntransition_to(\"shipped\")\ntransition_to(\"returned\")\n```\n\n\nIf `VALID_ORDER_STATUSES` were a regular set, any caller could `.add(\"returned\")` to it and silently expand the allowed list for the rest of the program. Making it a `frozenset` documents that the list is fixed and stops accidental mutation at the type level. There's a real production lesson there: any constant that ought to behave like a constant should be immutable.\n\n---\n\n# set vs frozenset Side by Side\n\nA direct comparison of the two types:\n\n\n| Feature | `set` | `frozenset` |\n| ---------------------------------------- | --------------------------- | --------------------------------- |\n| Literal syntax | Yes (`{1, 2, 3}`) | No (constructor only) |\n| Mutable | Yes | No |\n| Hashable | No | Yes |\n| Usable as a dict key | No | Yes |\n| Usable as an element of another set | No | Yes |\n| `add`, `remove`, `discard`, `pop`, `clear` | Yes | No (`AttributeError`) |\n| `update` and `|=`, `&=`, `-=`, `^=` | Yes | No (method missing or `TypeError`)|\n| `in`, `len`, iteration | Yes | Yes |\n| `union`, `intersection`, `difference` | Yes | Yes |\n| `issubset`, `issuperset`, `isdisjoint` | Yes | Yes |\n| Average lookup cost | O(1) | O(1) |\n| Equality with the other type | Equal if elements match | Equal if elements match |\n\n\nThe two types share the entire read-only API and the same average performance. The mutable methods are the dividing line, and hashability is the payoff for giving them up.\n\nThat last row deserves a closer look. A `set` and a `frozenset` with the same elements compare as equal under `==`, even though they're different types:\n\n\n```python\na = {1, 2, 3}\nb = frozenset({3, 2, 1})\nprint(a == b)\nprint(b == a)\n```\n\n\nEquality is based on the elements they contain, not the wrapping type. That's helpful when one part of your code uses a set and another part uses a frozenset for the same logical concept. They'll still compare equal where it matters. They are not the same object, though, and `type(a) == type(b)` returns `False`. If you need to distinguish them, check the type explicitly.\n\n---\n\n# Mixing set and frozenset in Operations\n\nYou can pass a `set` and a `frozenset` to the same operation. The mechanics work fine, but the return type depends on whether you use the operator form or the method form.\n\n### Operator form: result type follows the left operand\n\n\n```python\ns = {\"a\", \"b\", \"c\"}\nf = frozenset({\"b\", \"c\", \"d\"})\n\nprint(type(s | f)) # set on the left\nprint(type(f | s)) # frozenset on the left\nprint(type(s & f))\nprint(type(f - s))\n```\n\n\nThe operator looks at its left operand to decide what to build. If the left side is a `set`, you get a `set` back. If the left side is a `frozenset`, you get a `frozenset` back. The right operand is just a source of elements.\n\n### Method form: result type follows the receiver\n\n\n```python\ns = {\"a\", \"b\", \"c\"}\nf = frozenset({\"b\", \"c\", \"d\"})\n\nprint(type(s.union(f)))\nprint(type(f.union(s)))\nprint(type(s.intersection(f)))\nprint(type(f.difference(s)))\n```\n\n\nWhen you call `f.union(s)`, the method is defined on `frozenset`, so the result is a `frozenset`. When you call `s.union(f)`, the method is defined on `set`, so the result is a `set`. The rule is \"whichever type owns the method you called\".\n\nThe practical takeaway: if you want the result to be a `frozenset`, either start from a `frozenset` on the left, call the method on a `frozenset`, or wrap the result with `frozenset(...)` explicitly. Don't rely on accidentally getting the right type out of a mixed expression.\n\n\n```python\npermissions = frozenset({\"read\", \"write\"})\nextra = {\"delete\"}\n\n# Easiest: start from the frozenset.\nmerged = permissions | extra\nprint(type(merged), merged)\n\n# Or wrap explicitly, which is unambiguous.\nmerged_explicit = frozenset(permissions | extra)\nprint(type(merged_explicit), merged_explicit)\n```\n\n\nThe explicit wrap is slightly more verbose, but it makes the intent obvious to anyone reading the code later. In code that mixes the two types, that clarity is usually worth the extra characters.","pageType":"python"}

Frozen Sets

Get Premium