*args and **kwargs: two stars with different prices — and one of them makes unknown names acceptable

strict(a=1, unknown=9)                         TypeError
loose(a=1, unknown=9)                          a=1 b=2 kwargs={'unknown': 9}
loose()                                        TypeError        ← required parameter
loose(1, a=2)                                  TypeError        ← passed twice
positional_only_loose(a=1, b=2, c=3)           TypeError        ← a name instead of a position

Base: a star on the two sides of a call

A star has several roles in Python, and all of them are written with the same character. Until the roles are pulled apart, any conversation about *args and **kwargs goes round in circles, so let us pull them apart first.

What tells the roles apart is the side: a star means one thing where a function is declared and the opposite where it is called.

In a declaration a star collects. It takes whatever found no parameter of its own and puts it under a single name:

• one star collects the surplus positional arguments — the ones passed by position;
• two stars collect the surplus keyword arguments — the ones passed by name.

In a call a star spreads. It takes a ready container and supplies its contents as separate arguments:

• one star spreads a sequence into positional arguments: f(*seq) is the same thing as f(seq[0], seq[1], …);
• two stars spread a dict into keyword arguments: f(**mapping) is f(name=value, …) for every pair.

Here are those roles side by side, with a last row for the form that uses the star quite differently:

Four different operations, and the confusion between the first two is the commonest: f(*args) inside a wrapper does not build a tuple, it takes apart one that already exists. The last row has nothing to do with collecting at all, and it gets a section of its own further down.

And here is the question the rest of the lesson answers: what does that collecting cost? It is written with one character and looks free — but it has a price in time and, on top of that, a consequence time does not measure.

That is already enough to answer the basic interview question. Everything below is about what arrives being a tuple and a dict rather than something arbitrary; about two stars costing four times what one costs at the call site; and about a name the function does not have ceasing to be an error the moment two stars appear in the declaration.

Mechanism 1: what these objects are

Start with what one function settles.

def collect(*args, **kwargs):
    return type(args).__name__, type(kwargs).__name__

collect(1, 2, x=3) returns ('tuple', 'dict'). Not a list — a tuple, and one line settles it: args.append(3) gives AttributeError: 'tuple' object has no attribute 'append'. There will be no mutable container here, however many arguments arrive.

The second and less obvious part: the objects are created even when there is nothing to deliver.

def probe(*args, **kwargs):
    return args, kwargs
 
probe()   # -> ((), {})

Not None, but an empty tuple and an empty dict. The language reference puts it exactly so: *identifier "is initialized to a tuple receiving any excess positional parameters, defaulting to the empty tuple". So if args: is the right check, while if args is not None: is always true.

What the function's own code knows about the stars

def full(a, b=2, *args, c, d=4, **kwargs):
    pass

The signature looks tangled, but the interpreter breaks it into three independent numbers and two flags:

From which follows the simple fact that clears up the main confusion: c and d became keyword-only not because they have defaults but because they stand after *args. That is the rule from PEP 3102, and a bare * in the signature does the same without collecting a tuple.

The order of keyword arguments is preserved: order(z=1, a=2, m=3) yields keys as ['z', 'a', 'm'], not sorted.

Mechanism 2: the bug that never crashes

A connection function. Three understandable parameters, and someone added a fourth — "in case something needs passing through to the driver".

def connect(host, port=5432, timeout=30, **options):
    ...

Six months later, in another file, someone writes a call:

connect("db", timeuot=5)

There is no error. timeuot is a legal key for **options, so the function receives timeout = 30 while the 5 lands in options, where nobody looks. The connection is made, the program carries on, and the difference shows up one day under load — as a timeout nobody expected.

Without **options the same call fails at once, and fails informatively.

Why this got worse rather than better

In 3.13 the interpreter learned to suggest the right name. What's New says: "The error message now tries to suggest the correct keyword argument when an incorrect keyword argument is passed to a function". Verified on all four versions:

So the language got better at catching this exact typo — and a function declared with **kwargs throws that help away. With it, 3.14 behaves just like 3.11: it says nothing.

What actually fixes it

Not vigilance. If **kwargs really is needed, then a check for unknown keys where they are accepted:

KNOWN = {"sslmode", "application_name"}
 
def connect(host, port=5432, timeout=30, **options):
    unknown = set(options) - KNOWN
    if unknown:
        raise TypeError(f"unknown parameters: {', '.join(sorted(unknown))}")

Four lines restore the refusal on an unknown name — the one that stopped happening by itself the moment those names became acceptable. And if **kwargs was not needed, its absence is the check — for free.

Mechanism 3: / and the bare * — on taking names

Two things from PEP 570 and PEP 3102 that have a measurable consequence, not merely a cosmetic one.

The bare * forbids passing anything after it positionally:

def open_conn(host, *, timeout=30, retries=3):
    ...

Now open_conn("db", 5) is an error rather than a five-second timeout that arrived by counting. The order of parameters stops being part of the contract, and can be changed without breaking callers.

The slash / does the opposite — it forbids passing by name. And it exists not for symmetry but for a reason only a run makes visible:

def name_taken(name, **kwargs):
    return name, kwargs
 
def name_free(name, /, **kwargs):
    return name, kwargs

While a parameter can be passed by name, that name is taken: a key of the same name cannot reach **kwargs. PEP 570 names this very case: "A key scenario is when a function accepts any keyword argument but can also accepts a positional one".

This is how dict itself is declared. Its signature is visible from the interpreter:

dict.__init__.__text_signature__   # ($self, /, *args, **kwargs)
dict(self="x")                     # {'self': 'x'}

The slash releases the name self — without it, dict(self="x") would give got multiple values for argument 'self'.

Mechanism 4: what a wrapper does to a signature

*args, **kwargs in a decorator has a side effect that is invisible in the wrapper's own code.

def wrap(fn):
    def inner(*args, **kwargs):
        return fn(*args, **kwargs)
    return inner

inspect.signature reports (*args, **kwargs) for such a wrapper — the parameter names are gone, and with them editor hints and half the value of type checking. @functools.wraps(fn) cures that, and afterwards the signature shown is the original: (host, port=5432, timeout=30).

But it does not describe what the wrapper will accept. Verified: the wrapper passes five positional arguments and any keyword name straight through, checking nothing. The call then fails inside: connect() takes from 1 to 3 positional arguments but 5 were given. @wraps gives the signature back to the tooling without making the wrapper obey it.

It shows in the traceback too: there is one frame more than there are layers — your own call frame plus one per wrapper.

The message always names the inner function — @wraps copied its name, so the two cannot be told apart by text. The frames differ: without @wraps the traceback shows three consecutive inner frames before the line with the typo.

Mechanism 5: typing — giving the erased names back

This is the only automatic way to restore what **kwargs erases.

Before 3.12, **kwargs could be annotated only with one type for all values. PEP 692 names the limitation outright: "Currently **kwargs can be type hinted as long as all of the keyword arguments specified by them are of the same type. However, that behaviour can be very limiting". From 3.12 there is Unpack[TypedDict]:

class Options(TypedDict, total=False):
    sslmode: str
    application_name: str
 
def connect(host: str, **options: Unpack[Options]) -> None:
    ...

Now a type checker — mypy, pyright — sees names again and catches timeuot=5 before the code runs: error: Unexpected keyword argument "timeuot". The call itself is unaffected: the interpreter still accepts it in silence — to it, the name is acceptable. The refusal on an unknown name comes back from outside, before the run, since inside the call it is gone.

Deeper: what the stars cost

Seven call forms measured back to back in one process: four are ways of passing two numbers to plain, three do the same through a function with stars and through wrappers.

The point here is the asymmetry. The two stars are written side by side, named in one breath, and priced entirely differently:

• plain(*args) — ×1.1–1.3 of a direct positional call. Practically free.
• plain(**kwargs) — ×4.0–5.2. More than fourfold.

The reason is visible in the bytecode, and it is more specific than "a dict is more complicated than a tuple". Identical on all four versions:

plain(*ARGS)      LOAD_GLOBAL LOAD_GLOBAL CALL_FUNCTION_EX
plain(**KWARGS)   LOAD_GLOBAL LOAD_CONST BUILD_MAP LOAD_GLOBAL DICT_MERGE CALL_FUNCTION_EX

On the calling side the tuple goes in as it is: CALL_FUNCTION_EX receives a ready object. Inside, a function with *args will build a tuple of its own — g(*T) is T is False — but that happens on an ordinary call too. Before a call with a dict, the interpreter builds a new dict (BUILD_MAP) and copies the given one into it (DICT_MERGE) — so the dict is copied on every call, before name matching even begins. Hence the fourfold gap.

Passing by name works differently and costs less: it compiles not to CALL_FUNCTION_EX but to CALL_KW, with a ready tuple of names among the constants — no dict is built at all. Hence the gap: ×1.3–1.9 against the four and more of plain(**kwargs). That is not an argument against keyword arguments — readability is worth more than ten-odd nanoseconds (on 3.13.7 the gap came to 11.3 ns) — but it is an argument against treating them as free inside a hot loop.

Wrappers stack

A decorator built on *args, **kwargs does both jobs at once: it receives with stars (building a tuple and a dict) and passes with stars (taking them apart again).

At three layers, eight ninths of the time goes into getting to the work rather than doing it. This is not an argument against decorators — it is an argument for knowing where they are expensive: in a handler that hits a database those hundreds of nanoseconds are invisible; in a function called a million times per pass they become a visible share.

Version history

How to answer in an interview

The short answer: a star in a declaration collects, a star in a call spreads. One star collects the surplus positional arguments into the tuple args, two collect the surplus keyword arguments into the dict kwargs; in a call, one spreads a sequence into positional arguments and two spread a dict into keyword arguments. Both objects are built even when there is nothing to pass: you get () and {}, not None.

That is enough to answer correctly. What follows is what you add if the interviewer digs.

If the interviewer digs deeper

First, price, and the two stars do not share it: plain(*args) is almost free, while plain(**kwargs) costs four times a direct call or more — consistently across all four versions.

What separates a good answer: naming not the cost but the fact that a **kwargs added "for flexibility" makes unknown keyword names acceptable. The call connect("db", timeuot=5) stops being a TypeError and quietly lands in options, while timeout stays equal to 30. Worse, since 3.13 the interpreter can suggest the right name — and a function with **kwargs throws that help away, behaving on 3.14 exactly as it did on 3.11.

Next they ask

Common misconceptions

Practice

Two exercises. Answer first, then check against the real output: in both, the right answer comes from a recorded run rather than from an editor.

def connect(dsn, timeout=30, **options):
  return timeout, options


print(connect("db", timeout=5))
print(connect("db", timeuot=5))

(5, {})
(30, {'timeuot': 5})

(5, {})
(5, {})

(5, {})
(30, {})

(5, {})
Traceback (most recent call last):
TypeError: connect() got an unexpected keyword argument 'timeuot'

Knowledge check