*args, **kwargs, and unpacking

A normal function signature declares a fixed number of parameters, and calling it with the wrong count is an error — which is exactly right most of the time, but sometimes a function genuinely needs to accept an unknown, variable number of arguments. print() is the obvious built-in example: print(1), print(1, 2), and print(1, 2, 3, 4, 5) are all valid, and Python's own function signature has to somehow allow for that.

The * before a parameter name tells Python: "gather every remaining positional argument into a tuple with this name." args is just a convention, not a keyword — *numbers works exactly the same way — but *args is what you'll see in almost every codebase, and deviating from it without a reason just makes code harder to skim. Inside the function, args behaves like any other tuple: iterate over it, index into it, pass it to sum().

** before a parameter name does the same thing for keyword arguments — anything passed as key=value that doesn't match a named parameter gets collected into a dict named kwargs (again, a strong convention, not a requirement). This is what lets a function accept an open-ended, named set of options without declaring every possible one up front.

Python requires a fixed order: regular positional parameters first, then *args, then **kwargs — this isn't a style preference, it's the only order Python's parser accepts. username is matched first because it's declared explicitly; everything else positional falls into args, everything else keyword falls into kwargs.

The same two symbols do the opposite job at a call site instead of a function definition — spreading a collection back out into individual arguments, rather than gathering individual arguments into a collection:

This is genuinely the same underlying idea in reverse: *args in a definition packs loose arguments into a tuple; * at a call site unpacks a tuple (or list, or any iterable) into loose arguments. The same relationship holds for ** and dicts. Confusing "packing" and "unpacking" is the single most common source of */** mistakes — the direction depends entirely on whether the asterisk appears in a def or in a call.

Decorators, covered in their own lesson, rely on exactly this: a wrapper function is written as def wrapper(*args, **kwargs) specifically because it has no idea what arguments the function it's wrapping will be called with — collecting everything generically and passing it straight through (func(*args, **kwargs)) is what lets one decorator work on any function, regardless of that function's own signature. This is also how Django's class-based views and many library APIs forward arguments through layers of wrapping without needing to know each layer's exact signature.