How does the * in a Python def differ from the * in a call like f(*args)?

### One symbol, two opposite jobs The single `*` and double `**` mean different things depending on where they are written, and conflating the two is one of the most common intermediate-level mistakes in Python. **In a `def`, the star packs.** `def f(*args, **kwargs)` declares parameters that *collect*: the leftover positional arguments are gathered into a `tuple` bound to `args`, and the leftover keyword arguments into a `dict` bound to `kwargs`. This is the receiving side. **In a call expression, the star spreads.** `f(*items)` takes the iterable `items` and passes each of its elements as a *separate positional argument*. `f(**options)` takes the mapping `options` and passes each key/value pair as a *separate keyword argument*, as though you had typed `f(key1=value1, key2=value2)`. This is the sending side. So `f(*[1, 2])` is exactly `f(1, 2)` — two arguments — while `f([1, 2])` is one argument that happens to be a list. Candidates who say "`f(*args)` passes the tuple" have the direction backwards. ### What each side accepts The `def` side is fixed: `args` is a tuple, `kwargs` is a dict, always. The call side is deliberately looser. `*` accepts **any iterable**, not just a tuple or list — a string (spreading into individual characters), a `set` (with no defined order), a generator object (which is consumed by the call), a `range`. `**` requires a **mapping** with string keys; anything else raises `TypeError`, and a non-string key raises `TypeError: keywords must be strings`. ### The forwarding idiom Put the two sides back to back and you get the pattern the leaf is really about: ```python def wrapper(*args, **kwargs): return target(*args, **kwargs) ``` The first line packs whatever arrived; the second unpacks it into `target`. The net effect is that `target` sees precisely the arguments the original caller wrote — same values, same positions, same keyword names — and the wrapper never had to know `target`'s parameter list. That is why every generic wrapper, adapter, retry helper, timing helper and delegating subclass method in the ecosystem is spelled this way. Two details make the round trip exact. First, the pack/unpack pair preserves the positional/keyword *split*: an argument the caller wrote positionally arrives at `target` positionally, and one written as a keyword arrives as a keyword. Forwarding does not "normalise" everything into keywords. Second, `kwargs` preserves the order the keywords were written, so relaying it is order-stable too. ### Where the errors move The wrapper's own signature now accepts anything, so **argument validation is deferred**. If the caller supplies too few arguments, the `TypeError` is raised by `target`, and the traceback points at the wrapper's forwarding line rather than at the caller's mistake. If `target` has a strict signature, that check still happens — just one frame later. If `target` *also* ends in `**kwargs`, no check happens at all. The same applies to introspection: a wrapper written this way reports "takes any arguments", so editor help, generated docs and static type checking degrade to nothing useful for its callers. That is the price of the idiom, and it is why you declare a real signature whenever you can name one. ### Adjusting a call before forwarding Because `args` is a tuple and `kwargs` a dict, you can inspect or edit them before relaying: ```python def wrapper(*args, **kwargs): kwargs.setdefault("timeout", 5) return target(*args, **kwargs) ``` Mutating `kwargs` is safe — it is a fresh dict built for this call, not the caller's mapping. To change a positional argument, convert to a list first, since the tuple is immutable. Reaching for `kwargs["name"]` blindly is a trap: the key exists only if the caller actually wrote that keyword, so use `dict.get` or `dict.pop` with a fallback. ### Reading a call site quickly Two habits make star-heavy code easy to read. First, ask whether the star sits next to a *parameter name* in a `def` (collecting) or next to a *value* in a call (spreading) — that single distinction resolves almost every confusion. Second, mentally rewrite the call: `send(*row, **headers)` becomes "pass each element of `row` positionally, then each entry of `headers` by name", which immediately tells you how many arguments the callee will see and therefore whether its signature can accept them. A related trap is the temptation to spread something that is not really a sequence of arguments. `f(*some_string)` is legal and passes one argument per character; `f(*mapping)` spreads the *keys*, because iterating a dict yields keys. Both run happily and produce nonsense, so a star applied to a value whose element count you cannot state is a smell worth pausing on. ### A mental summary Reading a star in Python is a two-step question: *am I in a definition or in a call?* In a definition, the star is a funnel pointing inward — many arguments become one object. In a call, the star is a funnel pointing outward — one object becomes many arguments. The forwarding idiom is simply both funnels connected end to end.