How do Counter's +, -, & and | operators differ from Counter.update() and Counter.subtract()?

## Two families of combination `collections.Counter` gives you two ways to combine counts, and they differ on three axes at once: **new object vs in-place**, **non-positive counts dropped vs kept**, and **Counter-only vs any iterable or mapping**. Confusing them is one of the most common real bugs in counting code. ### The operator family: multiset algebra ```python from collections import Counter inv = Counter(a=3, b=1) sold = Counter(a=1, b=2) inv + sold # Counter({'a': 4, 'b': 3}) sum inv - sold # Counter({'a': 2}) difference, b dropped inv & sold # Counter({'a': 1, 'b': 1}) per-key minimum (intersection) inv | sold # Counter({'a': 3, 'b': 2}) per-key maximum (union) ``` All four: - return a **new** Counter and leave both operands untouched; - compute per key, treating a key absent from one side as count 0; - **omit any key whose result is zero or negative**. That is the multiset rule — a multiset cannot contain minus one of something — and it is why `b` vanishes from `inv - sold` instead of appearing as `-1`. They also require both operands to be Counters. `Counter(a=1) + {"a": 1}` raises `TypeError`; the operator returns `NotImplemented` for a non-Counter and nothing else handles it. Wrap the dict — `c + Counter(d)` — or use `update()`. There are two unary operators in the same family: `+c` returns a new Counter holding only the positive counts (the documented way to strip zeros and negatives after a `subtract()`), and `-c` returns the negated counts that were negative. ### The method family: in-place arithmetic ```python inv = Counter(a=3, b=1) inv.subtract(Counter(a=1, b=2)) inv # Counter({'a': 2, 'b': -1}) ``` `Counter.update()` and `Counter.subtract()` mutate the receiver and return `None`. They keep the arithmetic exactly as computed: zeros stay, negatives stay. And they are liberal in what they accept — another Counter, a plain mapping of counts, or a bare iterable of elements: ```python c = Counter() c.update("aab") # iterable of elements -> Counter({'a': 2, 'b': 1}) c.update({"a": 10}) # mapping of counts -> Counter({'a': 12, 'b': 1}) c.subtract(["a"]) # iterable again -> Counter({'a': 11, 'b': 1}) ``` The `update()` behaviour is worth calling out on its own, because it silently overrides the inherited one: `dict.update()` **replaces** a value, `Counter.update()` **adds** to it. Someone reading `c.update({"a": 10})` as a dict operation will expect `a == 10` and get `a == 12`. ## Choosing between them The question behind the question is: *is a deficit meaningful?* - If you are computing "what is left over", "what do both have in common" or "what is the merged total", the operators are right — the non-positive pruning is the semantics you want, and the fresh object keeps the inputs intact. - If you are tracking a running balance, a drift, or an outstanding shortfall, `subtract()` is right, because the negative count **is** the answer. Dropping it silently turns "we are two short" into "we have none of these", which reads the same as "we never had any". - If your right-hand side is a raw stream of elements rather than a Counter, only `update()` and `subtract()` will take it. There is a performance dimension too: `update()` mutates one object, while chaining `total = a + b + c + d` allocates an intermediate Counter at every step. For a merge over many partial counters, `for part in parts: total.update(part)` avoids that garbage. ## A worked example of the difference mattering Reconciling counted stock against a shipment manifest is the canonical case. `on_hand - shipped` answers "what is still on the shelf", and the pruning is right: an item you are short of is not on the shelf in a negative quantity, it is simply not there. But `on_hand.subtract(shipped)` answers a different question — "where are we out of balance" — and only that form can report the shortfall. Write the first when you are producing a picture of reality, the second when you are producing a discrepancy report. Choosing the operator because it reads more nicely, and then wondering why shortages never appear in the output, is a bug that survives code review precisely because the code looks clean. ## The comparison operators Since Python 3.10, Counters also support `<`, `<=`, `>` and `>=` as multiset containment tests: `Counter(a=1) <= Counter(a=2, b=1)` is `True`, meaning every count on the left is at most the matching count on the right. `==` remains ordinary dict equality, so a zero-count key makes two Counters unequal even though they describe the same multiset — another reason to strip with unary `+` before comparing. ## What to say in an interview Give the three axes — new vs in-place, drops non-positive vs keeps it, Counter-only vs any iterable — then show the one-line example where `-` and `subtract()` disagree. Adding that `Counter.update()` adds where `dict.update()` replaces usually ends the topic.