Mastery
Mastery/Python/C. Functions & closures
T1 · high-leverage

*args/**kwargs: collection vs unpacking, and ordering rules

*args/**kwargs in a function definition COLLECT extra arguments; the same syntax at a call site UNPACKS a sequence/mapping into separate arguments. A call can mix positional, *iterable, keyword, and **mapping unpacking, but Python enforces a strict order, and duplicate keyword collisions raise immediately rather than silently picking one.

python
def show(*args, **kwargs):
    print("args:", args, "kwargs:", kwargs)

show(1, 2, 3, x=4, y=5)

nums = [1, 2, 3]
opts = {"x": 4, "y": 5}
show(*nums, **opts)          # unpack at call site
show(0, *nums, z=9, **opts)  # mixing positional, unpack, keyword, unpack

try:
    d1 = {"x": 1}
    d2 = {"x": 2}
    show(**d1, **d2)   # duplicate key across two unpacked dicts
except TypeError as ex:
    print("TypeError:", ex)

Interview angle

Commonly tested with a "predict this function call" question mixing positional args, unpacked iterables, keyword args, and unpacked mappings — getting the precedence and collision rules right (and knowing exactly which combination raises TypeError) shows real fluency, versus knowing *args/**kwargs only as buzzwords to drop into a sentence.

In the industry

This is the mechanism that makes decorators, mixins, and wrapper/proxy functions possible in virtually every non-trivial Python codebase — logging decorators, ORM method wrapping, web framework middleware all depend on transparently forwarding arbitrary arguments. If you can't unpack and forward arguments correctly, you can't write a general-purpose decorator, which makes this one of the highest-leverage topics for actually reading library and framework source code instead of just using it.