Python Function Arguments — Every Way to Pass Data In, Explained Properly

What Are Function Arguments in Python?

A function without inputs can only ever do one fixed thing. Arguments are what let the same function behave differently every time it's called — send_email("priya@example.com", subject="Invoice") and send_email("rohan@example.com", subject="Reminder") run identical code with different data plugged in. Arguments are the entire reason functions are reusable instead of just named blocks that always do the exact same thing.

Here's where Python genuinely stands apart from most beginner-friendly languages: it gives you five distinct ways to pass arguments into a function — positional, keyword, default-valued, arbitrary positional (*args), and arbitrary keyword (**kwargs) — and they can all coexist in a single function signature, in a specific, non-negotiable order. That flexibility is genuinely powerful once it clicks. Before it clicks, it's the source of some of the most confusing tracebacks a beginner will encounter, mostly because the error messages assume you already know the vocabulary they're using.

I still remember staring at TypeError: create_user() got multiple values for argument 'role' for a solid ten minutes before realising the actual problem: I'd passed role both positionally and as a keyword argument in the same call, and Python had absolutely no idea which one I actually meant. The error message is accurate. It's just written assuming you already know exactly what 'multiple values for one argument' means mechanically — which, the first time you see it, you don't.

This guide walks through every argument-passing style Python supports, the exact order rules the interpreter enforces, argument unpacking with * and ** at the call site, and — because it trips up almost everyone eventually — how Python actually passes arguments under the hood, which is neither strictly 'by value' nor strictly 'by reference' the way those terms work in C or Java.

History — How Python's Argument-Passing Syntax Grew Over Time

Python's argument system today is the product of several distinct additions over more than three decades, each solving a specific real-world pain point that developers had already run into.

• ▶

  1991 — Python 0.9.0 — Basic positional arguments existed from the very first release. Call a function, values get matched to parameters strictly by position, in order — the simplest and oldest form of argument passing in the language.

• ▶

  Early 1990s — Default Arguments — Default parameter values (def f(x=10):) were present very early on, letting callers omit arguments that have a sensible fallback, without needing separate overloaded function definitions the way C++ or Java would eventually require.

• ▶

  Early 1990s — Keyword Arguments — The ability to call a function by naming parameters explicitly (greet(name='Priya')) rather than relying purely on position was also part of Python's earliest design — a genuinely progressive feature for its era, when most mainstream languages offered only positional calling.

• ▶

  Early 1990s — *args and **kwargs — Variable-length argument collection using * and ** prefixes appeared early too, allowing functions like print() itself to accept any number of arguments without a fixed signature.

• ▶

  2008 — Python 3.0 (PEP 3102) — Introduced keyword-only arguments — parameters that must be passed by name, enforced using a bare * in the function signature. This gave library authors a way to force clarity at call sites for parameters where positional calling would be error-prone or ambiguous.

• ▶

  2018 — Python 3.8 (PEP 570) — Introduced positional-only parameters, marked using a / in the signature. This let standard library functions (many of which had already behaved this way informally in C implementations) formally declare that certain parameters cannot be passed by keyword — useful for letting a library rename an internal parameter later without breaking anyone who called it positionally.

• ▶

  2026 — Current state — All five styles — positional, keyword, default, *args, **kwargs — plus positional-only and keyword-only markers, now coexist in one unified, precisely ordered grammar. It's more rules to learn upfront than most beginner tutorials admit, but each one solves a genuinely distinct real problem, not academic completeness for its own sake.

Key Characteristics of Python Function Arguments

Here are the 11 things worth knowing precisely about how Python handles arguments — not the vague version, the exact one:

How Python Matches Arguments to Parameters — Flowchart

Every single function call goes through the same internal matching process before the function body even starts running — positional arguments get slotted in first, keyword arguments get matched by name, defaults fill whatever's left unfilled, and anything extra gets swept into *args or **kwargs. Here's that exact sequence.

Key insight: this entire binding process happens before a single line inside the function body runs. If it fails at any decision point, the function never executes at all — you get a clean traceback pointing at the call site, not a partially-run function with confusing half-completed side effects.

How Arguments Actually Work — Order Rules, Unpacking, and Reference Semantics

Three things separate someone who's memorised *args and **kwargs as magic syntax from someone who actually understands argument passing: the strict ordering rule for signatures, how unpacking works at the call site (not just the definition), and what 'passed by reference' really means in Python — because it is genuinely not the same as either C's pass-by-value or Java's pass-by-reference, despite people casually using both terms.

🔢 The Non-Negotiable Signature Order

A full Python function signature, using every available feature, follows exactly this order: def f(pos_only, /, standard, default=1, *args, kw_only, **kwargs):. Positional-only parameters come first, separated by a bare /. Then standard positional-or-keyword parameters. Then defaulted parameters. Then *args for extra positional values. Then keyword-only parameters, which can appear either after a bare * or right after *args itself. Finally **kwargs, always last. Writing a parameter with a default before one without a default — def f(a=1, b): — raises SyntaxError: parameter without a default follows parameter with a default immediately, because Python can't figure out what should happen if a caller supplies only one positional value.

🔓 Unpacking at the Call Site — Where * and ** Actually Shine

The * and ** prefixes aren't only for collecting arguments inside a definition — they also work in reverse, at the call site, to spread out an existing collection. If you have coordinates = (10, 20) and a function def move(x, y):, calling move(*coordinates) unpacks the tuple into two separate positional arguments — exactly equivalent to move(10, 20). Similarly, if user_data = {'name': 'Priya', 'age': 25} and a function def create_user(name, age):, calling create_user(**user_data) unpacks the dictionary into keyword arguments — exactly equivalent to create_user(name='Priya', age=25). This pattern shows up constantly when forwarding arguments between wrapper functions and the functions they wrap, which is exactly how most decorators are implemented internally.

🔗 Pass-by-Object-Reference — Neither Value Nor Reference, Exactly

This confuses developers coming from both C-style and Java-style backgrounds, because Python's actual behaviour is its own thing. When you pass an argument, Python passes a reference to the same underlying object — no copy is made. If that object is mutable (a list, dict, or set) and the function modifies it in place — my_list.append(4) — the caller's original object changes too, because there's only ever been one object the whole time. But if the function reassigns the parameter name to a brand new object — my_list = [1, 2, 3] — that reassignment only affects the local name inside the function; the caller's original variable still points at whatever it pointed at before. Immutable objects (strings, integers, tuples) behave as if passed by value in practice, simply because you can't mutate them in place at all — any 'change' to a string parameter is actually creating a new string object and rebinding the local name to it.

Simple rule to remember: positional binds by order, keyword binds by name, defaults fill gaps, *args/**kwargs sweep up the leftovers, and mutating a mutable argument in place affects the caller — reassigning it does not.

Positional vs Keyword vs Default vs *args vs **kwargs — Key Differences

Each argument style solves a genuinely different problem. This table lines up exactly what each one does, how it's written, and when to reach for it.

Passing Arguments — Python vs Other Languages

Python's argument flexibility is genuinely unusual compared to statically typed languages, and the contrast explains a lot about why Python APIs tend to look different from Java or C++ ones.

Here's my honestly opinionated take: Python's native keyword arguments are one of its most underrated design decisions, and I genuinely miss them whenever I write Java. A call like create_report(start_date='2026-01-01', end_date='2026-03-31', include_charts=True) is self-documenting at the call site — you don't need to open the function definition to know what each value means. Java developers simulate this with builder patterns or wrapper config objects, which works, but it's noticeably more ceremony to get the same clarity Python gives you for free with plain keyword syntax.

Advantages and Disadvantages of Python's Argument System

This much flexibility is a genuine strength, but it comes with real trade-offs, especially around clarity and API design discipline.

Argument Binding Architecture — From Call Site to Local Scope

The diagram below shows exactly where each argument style lives in the pipeline between writing a function call and that function's body actually starting to run.

Every Argument Style in One File — Plus the Errors They Produce

Here's a function using every style together, followed by the two most common argument-related errors and exactly what triggers them.

def build_profile(user_id, /, name, role="member", *tags, verified=False, **extra_info):
    print(f"ID: {user_id} (positional-only)")
    print(f"Name: {name}")
    print(f"Role: {role}")
    print(f"Tags: {tags}")
    print(f"Verified: {verified} (keyword-only)")
    print(f"Extra info: {extra_info}")

build_profile(101, "Ananya", "admin", "beta-tester", "early-access", verified=True, city="Pune")

Now the two errors that trip up almost everyone at some point — reproduced exactly:

def create_user(name, role="user"):
    print(f"{name} created with role {role}")

# Error 1: same argument supplied twice
create_user("Rohan", "admin", role="editor")

# Error 2: a required argument never supplied
# create_user(role="admin")

That specific error happens because "admin" was already passed positionally for role, and then role="editor" tried to bind it again by keyword — but since there are only 2 total parameters and 3 positional-looking values were supplied, Python actually reports the positional-count mismatch first. Removing the extra positional value and calling create_user("Rohan", role="editor") instead resolves it cleanly. The commented-out second case — calling with only role="admin" and no name — would raise TypeError: create_user() missing 1 required positional argument: 'name', since name has no default and nothing was ever supplied for it.

Practice This Code — Live Editor

Line-by-Line Explanation

• ▶

  user_id, /, — Everything before the / is positional-only. Calling build_profile(user_id=101, ...) would raise TypeError: build_profile() got some positional-only arguments passed as keyword arguments: 'user_id'.

• ▶

  name, role="member" — Standard positional-or-keyword parameters, with role defaulting to "member" if omitted.

• ▶

  *tags — Collects any additional positional arguments beyond name and role into a tuple — here, ('beta-tester', 'early-access').

• ▶

  verified=False after *tags — This makes verified keyword-only. It cannot be supplied positionally, only as verified=True or similar.

• ▶

  **extra_info — Collects any remaining keyword arguments not matching a named parameter — here, just city="Pune" — into a dictionary.

Where Argument Flexibility Actually Matters — Real-World Applications

This isn't abstract syntax trivia — Python's argument system shapes how real, widely-used APIs are designed:

• ▶

  🌐 Web Framework Configuration — Django model fields and view functions lean heavily on keyword arguments and defaults — CharField(max_length=100, blank=True, null=False) reads clearly precisely because every value is named at the call site.

• ▶

  🎨 Decorators and Function Wrapping — Every decorator that needs to work on functions with unknown signatures relies on *args and **kwargs to transparently forward whatever arguments the wrapped function actually needs, without knowing them in advance.

• ▶

  📊 Data Science Library APIs — pandas.read_csv() accepts dozens of optional keyword arguments (sep, header, dtype, na_values) with sensible defaults — exactly the kind of API that would be unworkable without native default and keyword argument support.

• ▶

  🔧 Configuration and Settings Objects — Functions that accept **kwargs as a flexible settings bag let calling code pass only the options it cares about, letting the function apply sensible defaults for everything else.

• ▶

  🧪 Test Fixtures and Parametrised Tests — pytest fixtures and parametrised test functions frequently use default arguments and keyword-only parameters to keep test setup explicit and readable, avoiding ambiguous positional test data.

• ▶

  🖼️ GUI and Plotting Libraries — matplotlib.pyplot.plot() accepts a long tail of optional style-related keyword arguments (color, linewidth, linestyle) — exactly the pattern **kwargs and defaults are built for.

• ▶

  🔌 API Client Wrappers — Functions wrapping third-party API calls often forward **kwargs directly into an underlying HTTP request library, letting callers pass through headers, timeout, or auth options without the wrapper needing to know every possible option in advance.

• ▶

  🧮 Mathematical/Statistical Utility Functions — Functions like a custom sum_all(*numbers) or average(*values) use *args to accept any number of numeric inputs without forcing callers to build a list first.

Why This Deserves Its Own Deep Dive, Not Just a Side Note

Most tutorials cover arguments as a quick aside inside a broader 'functions' lesson. Here's why that undersells the topic:

• ▶

  🐛 It's Where a Huge Share of TypeErrors Come From — missing required positional argument, got multiple values for argument, and unexpected keyword argument are three of the most common tracebacks in real Python codebases, and all three are purely argument-binding issues, not logic bugs.

• ▶

  💼 API Design Interviews Test This Directly — Being asked to design a function signature that accepts flexible configuration, or to explain why a mutable default argument is dangerous, is a genuinely common mid-level interview question.

• ▶

  🧠 It Explains Library Code You Read Daily — Once *args, **kwargs, and keyword-only parameters actually make sense, reading the source of libraries like requests or pandas stops feeling like decoding a puzzle.

• ▶

  🔧 It's Foundational for Writing Decorators — Every non-trivial decorator needs to forward arbitrary arguments to the function it wraps, which is impossible to do cleanly without a solid grasp of *args and **kwargs.

• ▶

  🔗 It Clarifies a Genuinely Common Point of Confusion — The 'pass by reference vs pass by value' confusion is one of the most frequently mis-explained topics online. Getting it right here prevents a category of bugs involving unexpectedly mutated lists and dictionaries.

• ▶

  🇮🇳 It's a Standard Deep-Dive Topic in Indian Python Courses — Beyond the basic def introduction, Indian engineering curricula and interview-prep bootcamps typically dedicate a full separate session to *args/**kwargs and argument order — exactly the scope of this guide.

Argument Unpacking — * and ** at the Call Site, Explained Further

Unpacking deserves its own close look, because the same symbols (* and **) mean something different depending on whether they appear in a function definition or at a call site — a distinction that confuses a lot of learners initially.

• ▶

  In a function definition — *args and **kwargs COLLECT extra arguments into a tuple and dictionary respectively. This is the 'gathering' direction.

• ▶

  At a function call — *some_list and **some_dict SPREAD an existing collection out into separate individual arguments. This is the 'scattering' direction — the exact opposite operation, using identical symbols.

• ▶

  Combining both directions — A very common real pattern: def wrapper(*args, **kwargs): return original_function(*args, **kwargs). Here the wrapper collects whatever it's called with, then immediately spreads those same values back out to call another function — this exact line is the backbone of most decorator implementations.

• ▶

  Unpacking multiple collections in one call — Python allows combining several unpacked collections in a single call: combined = [*list_a, *list_b] merges two lists, and merged = {**dict_a, **dict_b} merges two dictionaries, with keys from dict_b overriding matching keys from dict_a if there's a conflict.

Python Function Arguments — Interview Questions

These come up constantly in Python interviews, from fresher screening rounds to mid-level backend interviews focused on API design.

Practice Questions — Test Your Understanding

Work through these before checking the answers. Predicting exact output and exact error text is the real test here.

Conclusion — Master the Order, and the Errors Stop Being Scary

Every one of the confusing tracebacks covered in this guide — missing required positional argument, got multiple values for argument, got an unexpected keyword argument — traces back to the exact same underlying mechanism: Python trying, and failing, to bind the values you supplied to the parameters your function actually declared. Once that binding process is genuinely clear in your head, these errors stop being cryptic and start being precise, useful diagnostics that point you straight at the fix.

If you're a complete beginner, the priority is getting comfortable with plain positional and keyword arguments first — that alone covers the overwhelming majority of function calls you'll write. If you're moving into writing reusable libraries or decorators, the priority shifts toward *args, **kwargs, and unpacking, since forwarding arguments cleanly between functions is where these tools genuinely earn their complexity.

The habit worth carrying forward: whenever a function signature starts accumulating more than three or four parameters, especially a mix of optional ones, reach for keyword arguments at the call site even where positional would technically work. It costs a few extra characters and buys real clarity for whoever reads that call six months from now — quite possibly you.

Arguments are the actual interface of every function you write. Get the order rules solid, understand what unpacking does in both directions, and know exactly when mutation quietly leaks back to the caller — everything else about calling functions confidently follows from that. 🐍

Frequently Asked Questions (FAQ)