*args and **kwargs — Silent Typo Bugs in Python

Most Python tutorials show you args and kwargs as a syntax curiosity — a footnote after the 'real' stuff. That's backwards. These two features are why Python's standard library, every major framework, and every well-designed API you've ever touched actually works. Django's class-based views use kwargs to pass URL parameters. Python's built-in print() uses args so you can pass it one string or twenty. Decorators — the feature that powers Flask routes, pytest fixtures, and logging middleware — are almost impossible to write correctly without them.

But here's what tutorials miss: **kwargs hides typos. A misspelled keyword argument won't raise a TypeError — it'll just silently add a new key to the dict, and your function will ignore it (or worse, treat it incorrectly). I've debugged production incidents where a config value wasn't applied because someone wrote timeuut=30 instead of timeout=30. The function kept running, no error, just wrong behavior.

By the end you'll understand not just what args and *kwargs do, but when to use them, when to avoid them, and how to debug the silent failures they can create. You'll see real code from Django, Flask, and functools.wraps — the patterns that separate intermediate from senior Python developers.

Why Fixed-Argument Functions Break in the Real World

When you define a function like def add(a, b), you're making a promise: this function always takes exactly two things. That's fine for a calculator. It's not fine for the real world, where requirements shift.

Picture a logging utility. On day one you log a message and a level. On day two someone needs to attach a user ID. Day three, a request ID. If your function signature is rigid, you're back editing it every time. You'd end up with def log(message, level, user_id=None, request_id=None, session_id=None) — a parameter list that grows forever.

args and kwargs exist to solve exactly this. They're not shortcuts or hacks — they're a deliberate design pattern that says 'this function is designed to receive a variable number of inputs.' Understanding when to reach for them (and when not* to) is what separates intermediate from advanced Python.

How *args and **kwargs Actually Work Under the Hood

The asterisks aren't magic keywords — they're unpacking operators. When Python sees args in a function definition, it's an instruction: 'collect all remaining positional arguments into a tuple and bind that tuple to the name args.' The name itself is just a convention. You could write toppings or *scores and it would work identically.

Similarly, `**kwargs` says: 'collect all remaining keyword arguments into a dictionary.' The double asterisk means 'key-value pairs,' not just 'things.'

This matters because a tuple and a dictionary behave differently. You iterate over args with a simple for loop. You iterate over *kwargs with .items() to get both the key and the value. You can also use len(), slicing, and unpacking on args just like any tuple. kwargs gives you .get(), .keys(), and the full dict API.

The order of parameters in a function signature is strict: regular positional params first, then args, then keyword-only params, then *kwargs. Breaking this order raises a SyntaxError immediately.

The Pattern That Powers Real Frameworks: Decorator Forwarding

Here's where args and *kwargs stop being a curiosity and become genuinely essential. Decorators — the @something syntax you see on Flask routes, Django views, and test functions — work by wrapping one function inside another. The wrapper needs to call the original function. But the wrapper doesn't know what arguments the original takes.

This is the single most important real-world use case: writing a wrapper function that forwards every argument to the inner function without caring what those arguments are.

Without args and *kwargs, you'd have to write a different decorator for every possible function signature. With them, you write one decorator that works universally. This is also the pattern behind Python's functools.wraps, unittest.mock.patch, and virtually every middleware system you'll encounter in production code.

Once you understand this pattern, reading framework source code stops feeling like magic and starts feeling like recognizable building blocks.

When NOT to Use *args and **kwargs

Using args and *kwargs everywhere is a code smell, not a sign of skill. If your function always takes exactly two user IDs to compare, define it that way. Explicit signatures are self-documenting — they tell the caller exactly what's expected. IDEs can autocomplete them. Type checkers can validate them.

**kwargs in particular can hide bugs. If you misspell a keyword argument, Python won't raise a TypeError — it'll just silently add the misspelled key to the dict and your logic will skip it. With explicit parameters, Python catches the typo immediately.

The right time to use them: when you're genuinely wrapping or forwarding calls (decorators, middleware), when you're building a function that is intentionally variadic by design (like a custom print or log function), or when you're writing a base class method that subclasses will extend with their own signatures. The wrong time: when you're just being lazy about writing out three parameters.

Frequently Asked Questions