What happens when you append to a `collections.deque` created with maxlen?

## The bounded-buffer contract Passing `maxlen` turns `collections.deque` into a fixed-capacity buffer whose eviction policy is decided for you: **a push at one end that would exceed the bound removes an item from the other end.** The deque never grows past `maxlen`, never raises on a full push, and never tells you that something was dropped. Concretely: ```python from collections import deque d = deque([1, 2, 3], maxlen=3) d.append(4) # -> deque([2, 3, 4]) : the 1 is gone d.appendleft(0) # -> deque([0, 2, 3]) : the 4 is gone ``` The symmetry is the part people get wrong in interviews. `append` evicts from the *left*, `appendleft` evicts from the *right*: the new item always wins, and the loser is the one furthest from where you pushed. `extend` and `extendleft` are defined as repeated single pushes, so they obey the same rule per item; `deque(range(1000), maxlen=5)` is a legal way to keep only the last five values of a long iterable. `maxlen` is read-only after construction — `d.maxlen = 10` raises `AttributeError`. To change the bound you build a new deque from the old one: `d = deque(d, maxlen=10)`. Two edge values matter: `maxlen=None` (the default) means unbounded, so an unbounded deque still reports `d.maxlen is None` rather than a number; and `maxlen=0` is accepted, producing a deque that swallows every push and stays empty, which is occasionally useful as a null sink. ## Why the bound is the point The failure this prevents is unbounded memory growth in a long-running process. Consider a route-optimisation job that keeps every intermediate solution it computes so it can report on recent progress. Written with a list and `results.append(...)`, the collection grows for the lifetime of the run; on a long job the process RSS climbs until the box or the container limit stops it, and the fix people reach for first — an occasional `del results[:-500]` — is a linear copy that they must remember to call from every code path. `results = deque(maxlen=500)` moves the policy into the data structure: eviction is O(1), it happens on the push itself, and there is no cleanup path to forget. The same shape covers a rolling log tail, the last N latency samples, a fixed-size undo trail, and a small cache of recently solved sub-problems. ## What a bounded deque is *not* It is not a cache with lookup. A bounded deque gives you recency-ordered *storage*, not membership testing: `x in d` is a linear scan, and `d[i]` in the middle is O(n) because of the block-chain layout. If a worker wants a hit rate off recent results — say the route job resolves 83% of leg requests from recently computed answers — the deque alone will scan itself on every lookup. Pair it with a dict keyed by the lookup key, or use `functools.lru_cache` when the thing you are caching is a pure function call and you want the eviction and the lookup handled together. It is also not a signal. Because eviction is silent, a bounded deque is the wrong structure when *dropping* is an event someone must react to — a dropped audit record, a dropped payment message. There you want an explicit capacity check that raises or applies backpressure, and for a producer/consumer handoff across threads that is `queue.Queue` with its own `maxsize`, which blocks or raises rather than discarding. The deque's contract is "the newest N matter and the rest do not", and you should say that out loud before choosing it. ## Small details that come up A bounded deque still supports `rotate`, `reverse`, `count`, `index` and iteration exactly as an unbounded one does. `d.insert(i, x)` on a *full* bounded deque raises `IndexError` rather than evicting, because insert has no obvious victim — that asymmetry with `append` surprises people. Copying preserves the bound: `d.copy()` and `copy.copy(d)` return a deque with the same `maxlen`. And `len(d)` is O(1) as always, so checking fullness is `len(d) == d.maxlen`. ## Compared with trimming by hand The alternative people write first is a list plus a trim: `buf.append(x)` followed by `if len(buf) > N: buf.pop(0)`. It is worse on three counts. It is O(n) per trim, because `list.pop(0)` shifts everything down. It is easy to get wrong — `>` versus `>=`, or a trim that runs on one append path but not another, so the bound silently stops holding on the branch nobody tested. And it puts the retention policy in the call sites rather than in the object, so a new caller that appends without trimming reintroduces the growth. `deque(maxlen=N)` moves all three problems into the constructor: the bound is a property of the container, it is enforced on every push from every call site, and the eviction is O(1).