{"title":"Set Methods","description":"","content":"Sets ship with a small but focused group of mutation methods: ways to add a single element, ways to remove an element (with or without a crash on a miss), bulk merges with any iterable, and in-place versions of the union, intersection, difference, and symmetric difference operations. This lesson walks through each one in an e-commerce setting, where a set is usually tracking active customers, products on sale, or tags applied to an order.\n\n---\n\n# `add`: Insert a Single Element\n\n`add(elem)` inserts `elem` into the set. If the element is already there, nothing happens. The set is mutated in place, and the call returns `None`.\n\n\n```python\nactive_customers = {\"alice@example.com\", \"bob@example.com\"}\nactive_customers.add(\"carol@example.com\")\nprint(active_customers)\n```\n\n\nThe set grows by one entry. The order in the output may differ on your machine, since sets don't keep a defined iteration order.\n\nThe interesting property is that `add` is idempotent: calling it with an element that's already in the set is a no-op. No error, no duplicate.\n\n\n```python\nactive_customers = {\"alice@example.com\"}\nactive_customers.add(\"alice@example.com\")\nactive_customers.add(\"alice@example.com\")\nprint(active_customers)\n```\n\n\nThree calls, but the set still has one element. This is exactly the property that makes sets useful for \"have I seen this before?\" tracking. You can `add` blindly without first checking with `in`, and the set takes care of deduplication.\n\n\n> **INFO**\n>\n> **Cost:** `add` is O(1) on average. The element is hashed and slotted directly into the underlying table.\n\n\nA common e-commerce use: tracking which customers have placed at least one order, where you don't care how many orders they placed, only whether they're active.\n\n\n```python\norders = [\n \"alice@example.com\",\n \"bob@example.com\",\n \"alice@example.com\",\n \"carol@example.com\",\n \"bob@example.com\",\n]\n\nactive_customers = set()\nfor email in orders:\n active_customers.add(email)\n\nprint(active_customers)\nprint(f\"Active customers: {len(active_customers)}\")\n```\n\n\nFive rows in, three customers out. The set quietly dropped the duplicate entries for Alice and Bob.\n\n`add` only accepts hashable elements. Trying to add a list raises `TypeError`, since lists aren't hashable.\n\n\n```python\ntags = set()\ntags.add([\"sale\", \"new\"])\n```\n\n\nIf you want to store something list-like, convert it to a tuple first: `tags.add((\"sale\", \"new\"))`. Tuples of hashable elements are themselves hashable.\n\n---\n\n# `remove` vs `discard`: Two Ways to Take One Out\n\nBoth `remove(elem)` and `discard(elem)` delete a single element from the set. The difference is what happens when the element isn't there.\n\n`remove` raises `KeyError` on a miss:\n\n\n```python\nactive_customers = {\"alice@example.com\", \"bob@example.com\"}\nactive_customers.remove(\"bob@example.com\")\nprint(active_customers)\n```\n\n\nThat worked because `\"bob@example.com\"` was in the set. Try the same call with a missing element:\n\n\n```python\nactive_customers = {\"alice@example.com\"}\nactive_customers.remove(\"dave@example.com\")\n```\n\n\n`discard` does the same removal but stays silent on a miss:\n\n\n```python\nactive_customers = {\"alice@example.com\"}\nactive_customers.discard(\"dave@example.com\")\nactive_customers.discard(\"alice@example.com\")\nprint(active_customers)\n```\n\n\nThe first `discard` does nothing, because the element wasn't there. The second one removes `\"alice@example.com\"`. No traceback, no exception. The set ends up empty, which is printed as `set()` rather than `{}` (since `{}` means an empty dict, not an empty set).\n\nThe choice between the two is the same kind of choice as `d[key]` versus `d.get(key)` for dictionaries. Use `remove` when the element being absent would mean a real bug and a crash is the most informative thing to do. Use `discard` when \"maybe present, maybe not\" is a normal case and you just want it gone if it's there.\n\n\n| Method | If element present | If element missing | Returns |\n| --- | --- | --- | --- |\n| `s.remove(elem)` | Removes it | Raises `KeyError` | `None` |\n| `s.discard(elem)` | Removes it | Does nothing | `None` |\n\n\n\n> **INFO**\n>\n> **Cost:** Both `remove` and `discard` are O(1) on average. The lookup-and-delete is the same operation as `add`, in reverse.\n\n\nA practical e-commerce example: when a customer unsubscribes, you want to drop them from the active set. You probably don't know for sure whether they were active to begin with (maybe they never placed an order), so `discard` is the right tool.\n\n\n```python\nactive_customers = {\"alice@example.com\", \"bob@example.com\", \"carol@example.com\"}\n\ndef unsubscribe(email):\n active_customers.discard(email)\n\nunsubscribe(\"bob@example.com\")\nunsubscribe(\"dave@example.com\")\nprint(active_customers)\n```\n\n\nBob is removed because he was active. Dave's unsubscribe is a no-op because he wasn't in the set. The function doesn't have to care which of the two cases it's hitting.\n\n### What's Wrong with This Code?\n\n\n```python\ndef unsubscribe(active, email):\n active.remove(email)\n\nactive_customers = {\"alice@example.com\", \"bob@example.com\"}\nunsubscribe(active_customers, \"bob@example.com\")\nunsubscribe(active_customers, \"dave@example.com\")\nprint(active_customers)\n```\n\n\nThe first call succeeds because Bob was in the set. The second call crashes because Dave never was. The function uses `remove`, which raises on a miss, but the calling code can't easily tell whether an email is in the active set before calling. The right tool for \"remove this if present, otherwise do nothing\" is `discard`.\n\n**Fix:**\n\n\n```python\ndef unsubscribe(active, email):\n active.discard(email)\n\nactive_customers = {\"alice@example.com\", \"bob@example.com\"}\nunsubscribe(active_customers, \"bob@example.com\")\nunsubscribe(active_customers, \"dave@example.com\")\nprint(active_customers)\n```\n\n\nSame logic, but `discard` swallows the miss instead of crashing. If you ever find yourself wrapping `remove` in a `try`/`except KeyError`, you almost certainly want `discard` instead.\n\nThe decision is easiest to picture as a flow:\n\n\n```mermaid\nflowchart TD\n Q[\"Need to remove
an element\"]:::cyan\n Q --> ASK{\"Is missing
a bug?\"}:::orange\n ASK -- \"Yes, crash\" --> RM[\"remove(elem)
raises KeyError
on miss\"]:::red\n ASK -- \"No, ignore\" --> DC[\"discard(elem)
silent on miss\"]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe decision point is whether absence is meaningful. If absence indicates a programming mistake or a corrupted state, `remove` and its `KeyError` are exactly what you want, because the crash tells you something is wrong. If absence is a normal case (\"maybe this customer was active, maybe not\"), `discard` keeps the code straight.\n\n---\n\n# `pop`: Remove and Return an Arbitrary Element\n\n`pop()` removes one element from the set and returns it. Unlike `dict.popitem`, you don't get to choose which one comes out, and the element isn't taken in any predictable order.\n\n\n```python\ntags = {\"sale\", \"new\", \"featured\"}\nremoved = tags.pop()\nprint(removed)\nprint(tags)\n```\n\n\nOn your machine the removed element might be `\"new\"` or `\"featured\"` instead. The result depends on how the hash table is laid out, which depends on the hash values of the elements and the table's current size. It's not random in the `random.choice` sense, but it's not LIFO like `dict.popitem` either.\n\nThis is what \"arbitrary\" means in the Python docs. The element insertion order does influence the layout (you don't get pure randomness), but you should treat the choice as unpredictable for your purposes. If you need to take a specific element out, look it up by value with `remove` or `discard`. If you need to take elements in insertion order, you're using the wrong data structure; reach for a list or a `collections.deque`.\n\n`pop` on an empty set raises `KeyError`:\n\n\n```python\nempty = set()\nempty.pop()\n```\n\n\nThere's no default-accepting form like `dict.pop(key, default)`. If you might be popping from an empty set, guard with a `while s:` check or wrap the call in a `try`/`except`.\n\n\n```python\nto_process = {\"order_101\", \"order_102\", \"order_103\"}\nwhile to_process:\n job = to_process.pop()\n print(f\"Processing {job}\")\n\nprint(f\"Done. to_process = {to_process}\")\n```\n\n\nThe exact order varies. The pattern itself, `while s: s.pop()`, is the cleanest way to drain a set when you don't care about ordering. It's common in \"process every pending job once\" loops where the work queue is naturally a set (because jobs shouldn't be duplicated).\n\n\n> **INFO**\n>\n> **Cost:** `pop` is O(1) on average. It walks the internal table to find the first non-empty slot and removes the element there.\n\n\n---\n\n# `clear`: Empty the Set in Place\n\n`clear()` removes every element. It mutates the set in place and returns `None`.\n\n\n```python\nactive_customers = {\"alice@example.com\", \"bob@example.com\", \"carol@example.com\"}\nactive_customers.clear()\nprint(active_customers)\n```\n\n\nJust like with lists and dicts, there's a difference between clearing a set in place and rebinding the name to a new empty set. The distinction matters when something else holds a reference to the same set.\n\n\n```python\nactive_a = {\"alice@example.com\", \"bob@example.com\"}\nsaved = active_a\n\nactive_a.clear()\nprint(saved)\n```\n\n\n`clear` empties the underlying set, and `saved` points to that same object, so it sees the change.\n\n\n```python\nactive_b = {\"alice@example.com\", \"bob@example.com\"}\nsaved = active_b\n\nactive_b = set()\nprint(saved)\nprint(active_b)\n```\n\n\n`active_b = set()` doesn't empty the existing set, it rebinds the name `active_b` to a brand-new empty set. The original set is untouched, and `saved` still holds onto it.\n\n\n| Form | Mutates the existing set? | Other references see the change? |\n| --- | --- | --- |\n| `s.clear()` | Yes | Yes |\n| `s = set()` | No (creates a new set) | No |\n\n\n\n> **INFO**\n>\n> **Cost:** `clear` is O(n), where n is the number of elements. Every entry has to be marked removed in the internal table.\n\n\nIf you only have one name pointing to the set, the two forms look identical. The moment something else holds a reference (a function caller, an attribute on a class, a stored value in a dict), the choice matters.\n\n---\n\n# `copy`: Shallow Copy\n\n`copy()` returns a new set containing the same elements as the original. Modifying one set afterward doesn't affect the other.\n\n\n```python\noriginal = {\"alice@example.com\", \"bob@example.com\"}\nduplicate = original.copy()\n\nduplicate.add(\"carol@example.com\")\nprint(original)\nprint(duplicate)\n```\n\n\nAdding to `duplicate` didn't touch `original`. That's the whole point: `copy` gives you an independent set object.\n\nThe \"shallow\" qualifier matters for dicts and lists, where values can themselves be containers. For sets, the qualifier is mostly academic, because every element must be hashable, and the everyday hashable types (numbers, strings, tuples of hashables, `frozenset`) are immutable. There's no way for \"the same element\" in two sets to be silently mutated through one and visibly change in the other.\n\nWhat `copy` does give you is a distinct set object, so adds and removes on one don't show up in the other.\n\n\n```python\noriginal = {\"alice@example.com\", \"bob@example.com\"}\nduplicate = original\nduplicate.add(\"carol@example.com\")\nprint(original)\n```\n\n\nWithout `copy`, the assignment `duplicate = original` doesn't make a new set, it just gives the same set a second name. `duplicate.add(\"carol@example.com\")` reaches the same object, and `original` sees the change. Compare with the explicit copy:\n\n\n```python\noriginal = {\"alice@example.com\", \"bob@example.com\"}\nduplicate = original.copy()\nduplicate.add(\"carol@example.com\")\nprint(original)\n```\n\n\nThis is the same trap that hits lists and dicts. Plain assignment never copies a mutable container; reach for `copy()` (or `set(other)`) when you need an independent set.\n\n---\n\n# `update`: In-Place Union with Any Iterable\n\n`update(iterable, ...)` adds every element from one or more iterables into the set, skipping anything already present. It mutates the set in place and returns `None`.\n\n\n```python\non_sale = {\"Wireless Mouse\", \"USB Cable\"}\nnew_sale_items = [\"HDMI Cable\", \"Wireless Mouse\", \"Webcam\"]\n\non_sale.update(new_sale_items)\nprint(on_sale)\n```\n\n\nThe duplicate `\"Wireless Mouse\"` was silently ignored because it was already in `on_sale`. The other two are inserted. `update` is in-place: there's no return value to assign, just the side effect on the set.\n\nThe key thing that separates `update` from the result-returning `union` method is that `update` accepts any iterable. A list, a tuple, a generator, a string (which iterates as its characters), a dict (which iterates as its keys), all are fair game. The `|` operator and the `union` method demand sets (or set-like things) on both sides.\n\n\n```python\non_sale = {\"Wireless Mouse\"}\non_sale.update([\"HDMI Cable\", \"USB Cable\"])\non_sale.update((\"Webcam\",))\non_sale.update(\"ab\")\nprint(on_sale)\n```\n\n\nThe list, tuple, and string are all valid inputs. The string `\"ab\"` iterates as its two characters, so `\"a\"` and `\"b\"` go in. That's a real footgun: if you meant to add the whole string `\"ab\"` as one element, you want `add`, not `update`. `update` always treats its argument as an iterable of elements to insert.\n\nYou can pass multiple iterables in one call:\n\n\n```python\non_sale = {\"Wireless Mouse\"}\non_sale.update([\"HDMI Cable\"], (\"Webcam\", \"Keyboard\"), {\"USB Cable\"})\nprint(on_sale)\n```\n\n\nEach argument is iterated in turn, and every element from each is added. This is convenient when you have items coming from several sources and want one merge call instead of several.\n\n\n> **INFO**\n>\n> **Cost:** `update` is O(len(other)) per iterable: each element is hashed and either inserted or skipped if already present.\n\n\nThe `|=` operator is the operator form for the dict-style case where you're merging another set in:\n\n\n```python\non_sale = {\"Wireless Mouse\"}\non_sale |= {\"HDMI Cable\", \"USB Cable\"}\nprint(on_sale)\n```\n\n\n`s |= other` is equivalent to `s.update(other)` when `other` is a set. The method form is broader, because it accepts any iterable; the operator form requires a set on the right.\n\n---\n\n# In-Place Intersection, Difference, and Symmetric Difference\n\nThe result-returning methods `intersection`, `difference`, and `symmetric_difference` each have an in-place version that mutates the receiver instead of producing a fresh set.\n\n\n| Result-Returning | In-Place |\n| --- | --- |\n| `s.intersection(other)` / `s & other` | `s.intersection_update(other)` / `s &= other` |\n| `s.difference(other)` / `s - other` | `s.difference_update(other)` / `s -= other` |\n| `s.symmetric_difference(other)` / `s ^ other` | `s.symmetric_difference_update(other)` / `s ^= other` |\n\n\nThe in-place versions return `None` and modify `s` directly. Like `update`, all three accept any iterable, not just a set.\n\n`intersection_update(iterable, ...)` keeps only the elements of `s` that are also in every iterable passed in. Everything else gets dropped.\n\n\n```python\nin_stock = {\"Wireless Mouse\", \"USB Cable\", \"HDMI Cable\", \"Webcam\"}\non_sale = [\"Wireless Mouse\", \"HDMI Cable\", \"Keyboard\"]\n\nin_stock.intersection_update(on_sale)\nprint(in_stock)\n```\n\n\nAfter the call, `in_stock` contains only the products that were both in stock and on sale. `USB Cable` and `Webcam` were in stock but not on sale, so they were dropped. `Keyboard` was on sale but not in stock, so it never gets added either; `intersection_update` only filters, never inserts.\n\n`difference_update(iterable, ...)` removes from `s` every element that appears in any of the iterables.\n\n\n```python\nactive_customers = {\"alice@example.com\", \"bob@example.com\", \"carol@example.com\", \"dave@example.com\"}\nunsubscribed = [\"bob@example.com\", \"dave@example.com\"]\n\nactive_customers.difference_update(unsubscribed)\nprint(active_customers)\n```\n\n\nEvery email in `unsubscribed` was dropped from `active_customers`. This is the bulk equivalent of calling `discard` in a loop, but with the benefit of being one expressive call.\n\n`symmetric_difference_update(other)` keeps the elements in exactly one of the two sets and drops the elements in both. Unlike the other two in-place mutators, it accepts only one argument (because \"symmetric difference of three sets\" isn't a meaningful single operation).\n\n\n```python\nyesterday_sale = {\"Wireless Mouse\", \"USB Cable\", \"HDMI Cable\"}\ntoday_sale = [\"HDMI Cable\", \"Webcam\", \"Keyboard\"]\n\nyesterday_sale.symmetric_difference_update(today_sale)\nprint(yesterday_sale)\n```\n\n\n`HDMI Cable` was in both, so it dropped out. The two `Wireless Mouse` and `USB Cable` items were only in yesterday's sale; the two `Webcam` and `Keyboard` items were only in today's. All four stay. The result is \"what changed between yesterday and today\".\n\nHere's how each in-place mutator transforms the same starting set:\n\n\n```mermaid\nflowchart LR\n START[\"s = {1, 2, 3, 4}\"]:::cyan\n OTHER[\"other = {3, 4, 5}\"]:::orange\n\n START --> U[\"update(other)
{1, 2, 3, 4, 5}\"]:::green\n START --> I[\"intersection_update(other)
{3, 4}\"]:::teal\n START --> D[\"difference_update(other)
{1, 2}\"]:::red\n START --> S[\"symmetric_difference_update(other)
{1, 2, 5}\"]:::orange\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nSame starting set, same `other`, four different ending states. `update` only grows the set; `intersection_update` only shrinks it; `difference_update` removes a chunk; `symmetric_difference_update` swaps in the \"exclusive to other\" elements while removing the shared ones.\n\nThe choice between the in-place form and the result-returning form comes down to whether you actually want a new set or are happy to mutate the existing one. If you need to keep the original around for other code to use, return-a-new-set is the safe pick. If you're done with the original and just want it to become the new value, the in-place form skips an allocation.\n\n---\n\n# Method Reference\n\nA consolidated table of every mutation method covered in this lesson, for quick lookup.\n\n\n| Method | Mutates? | Returns | Raises | Example |\n| --- | --- | --- | --- | --- |\n| `s.add(elem)` | Yes | `None` | Never (element must be hashable) | `s.add(\"Mouse\")` |\n| `s.remove(elem)` | Yes | `None` | `KeyError` on miss | `s.remove(\"Mouse\")` |\n| `s.discard(elem)` | Yes | `None` | Never | `s.discard(\"Mouse\")` |\n| `s.pop()` | Yes | Removed element | `KeyError` on empty | `removed = s.pop()` |\n| `s.clear()` | Yes | `None` | Never | `s.clear()` |\n| `s.copy()` | No | New set | Never | `dup = s.copy()` |\n| `s.update(iterable, ...)` | Yes | `None` | Never | `s.update([\"A\", \"B\"])` |\n| `s.intersection_update(iterable, ...)` | Yes | `None` | Never | `s.intersection_update(other)` |\n| `s.difference_update(iterable, ...)` | Yes | `None` | Never | `s.difference_update(other)` |\n| `s.symmetric_difference_update(other)` | Yes | `None` | Never | `s.symmetric_difference_update(other)` |\n\n\nTwo patterns to notice. First, every mutating method except `pop` returns `None`. `pop` returns the removed element because that's the whole point of the call. Second, the methods split into \"strict\" ones (`remove`, `pop`) that raise on a missing element or empty set, and \"lenient\" ones (`discard`) that stay silent. There's no defaulted form of `pop` for sets, unlike `dict.pop(key, default)`; on an empty set, `pop` always raises.\n\nEvery method in this table that mutates the set (which is all of them except `copy`) is unavailable on a frozenset. A frozenset is immutable, so it has `copy` and the result-returning set operations, but no `add`, `remove`, `discard`, `pop`, `clear`, `update`, or any of the `*_update` methods. That's not an oversight; it's the whole point of having a frozen variant.","pageType":"python"}

Set Methods

Get Premium