Why does a function taking **kwargs silently ignore a misspelled keyword, and how do you stop it?

### Why the typo is silent Python raises `TypeError: ... got an unexpected keyword argument 'x'` only when the function being called has **no home** for the name `x`. A `**kwargs` parameter is a home for *every* name. So the moment a signature carries a variadic keyword parameter, unknown-keyword detection is not weakened — it is **switched off** at that boundary and deferred to whoever downstream still has a strict signature. If nothing downstream does, the misspelled keyword never becomes an error. It becomes **data**: one unread entry in a dict that the function will discard when it returns. ### The shape it takes in production A feature-flag service ships a small client helper: ```python def is_enabled(flag, **options): return options.get("default", False) # plus a real lookup ``` A nightly export job — the one holding a 2.4 GB working set while it formats a report — calls `is_enabled("locale-aware-numbers", deafult=True)`. There is no exception, no warning, no log line. `options` is `{"deafult": True}`, `options.get("default", False)` returns `False`, the locale-aware formatter never switches on, and the export ships with a locale-dependent number format that is wrong for every non-English region. The defect is discovered months later by a human reading a spreadsheet, because the only artefact of the bug is a correct-looking `False`. Three variants of the same failure, worth naming in an interview: 1. The variadic function **reads keys itself** with `dict.get` and drops the rest — the case above. 2. The chain **ends in another `**kwargs` sink** — a config dict, a JSON payload, a logging extra — so no strict signature is ever reached. 3. The keyword is **shadowed by a default**: the parameter the caller meant to override has a perfectly reasonable default, so the wrong behaviour is plausible rather than obviously broken. ### The case where it *does* raise Forwarding into a strict callee restores the check: ```python def is_enabled(flag, **options): return evaluate(flag, **options) # evaluate declares real parameters ``` Now `evaluate` receives `deafult=True`, has no such parameter, and raises `TypeError`; CPython 3.14 even appends a closest-match suggestion ("Did you mean 'default'?"). The lesson is precise: **forwarding preserves the error, consuming destroys it.** ### How to prevent it * **Do not use `**kwargs` unless the option set is genuinely open.** Most functions that take one could name three parameters instead. A variadic signature you added "for flexibility" buys nothing and disables a real check for every future caller. * **Drain the bag.** If you must accept `**options`, `pop` the keys you understand and then refuse what is left: `if options: raise TypeError(f"unexpected keyword arguments: {sorted(options)}")`. Three lines, and the boundary behaves like a normal function again. * **Forward rather than consume.** Relay into the function that owns the real signature and let it validate; do not re-implement its option handling with `dict.get`. * **Type the signature.** A static type checker flags an unknown keyword at a precisely-typed call boundary, but it has nothing to check against when the signature is `**kwargs` typed as `object`. * **Test the negative case.** One test that calls the boundary with a bogus keyword and asserts a `TypeError` locks the behaviour in; without it, "silently ignores unknown options" is untested and therefore permanent. * **If you truly cannot raise, log.** Emitting a warning naming the unknown keys is far worse than raising and far better than silence, and it gives operations something to grep. ### One place the language drains the bag for you Constructor chains are the notable exception. If every `__init__` in a cooperative chain accepts `**kwargs` and relays it with `super().__init__(**kwargs)`, the leftovers eventually reach `object.__init__`, which accepts no extra arguments and raises `TypeError: object.__init__() takes exactly one argument (the instance to initialize)`. That is the same rule stated once more — the check happens at the first binding with no home for the name — and it is worth knowing because it explains an error message that otherwise looks like it came from nowhere. Break the chain by consuming the bag before the top, and the diagnostic vanishes again. That also illustrates why the traceback is unhelpful even in the cases that *do* raise: the exception is reported at the frame that finally bound the arguments, which may be several relays away from the caller who wrote the typo. The fix is the same as the prevention — validate at the boundary the caller actually touched, so the error names the function the caller actually called. ### The judgement to voice The instinct to blame the caller for the typo is the wrong instinct: the caller wrote something the API accepted. **A permissive signature is an API decision**, and "accepted and ignored" is the worst of the three possible behaviours — worse than rejecting, and worse than honouring. Senior work here is deciding which boundaries in a system are allowed to be variadic at all, and making every one that is either forward its bag to a strict consumer or validate it itself.