{"title":"Function Parameters","description":"","content":"When you call a function, the values you pass at the call site have to line up with the names declared in the function header. Python gives you two ways to make that connection (by position and by name), plus syntax to force callers into one mode or the other. This lesson covers what each piece does, when each one matters, and the exact error messages you'll see when the wiring goes wrong.\n\n---\n\n# Parameter vs Argument\n\nThese two words get used interchangeably in casual conversation, but Python's error messages care about the difference, and so should you.\n\nA **parameter** is the name in the function definition. It's a label that lives inside the function body. An **argument** is the value you pass at the call site when you invoke the function. Same connection, two ends, two words.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2)\n```\n\n\nIn the `def` line, `customer`, `item`, and `quantity` are **parameters**. At the call site, `\"Alice\"`, `\"Wireless Mouse\"`, and `2` are **arguments**. The parameters are the slots, the arguments are what you put in them.\n\nThis split shows up clearly in Python's tracebacks. When something goes wrong, Python tells you which side of the wall the problem is on. If a parameter has no matching argument, the error mentions the missing argument. If you pass an argument with a name that doesn't exist as a parameter, the error mentions the unexpected keyword argument.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\")\n```\n\n\nPython identifies `quantity` by its parameter name and labels it a \"required positional argument\". You'll see this exact shape of error several more times in this lesson. Read it carefully each time: the parameter name and the word \"argument\" together tell you which slot didn't get filled.\n\nThere's one more piece of vocabulary worth pinning down now: a **call signature** (or just **signature**) is the part of the function definition that lists the parameters. For `place_order` above, the signature is `(customer, item, quantity)`. When we discuss positional-only and keyword-only parameters later, we'll be talking about syntax that goes inside the signature.\n\n---\n\n# Positional Arguments\n\nA **positional argument** is an argument that binds to a parameter by **position**: the first argument goes to the first parameter, the second to the second, and so on. This is what you've been writing whenever you've called a function without naming the parameters at the call site.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"customer={customer}, item={item}, quantity={quantity}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2)\n```\n\n\n`\"Alice\"` lines up with `customer` because both are first. `\"Wireless Mouse\"` lines up with `item` because both are second. `2` lines up with `quantity` because both are third. The order at the call site has to match the order in the `def` header.\n\nThis works because Python walks through the parameters left to right and assigns the arguments in the order they appear. There's no name-matching happening at this point; it's pure position.\n\n\n```mermaid\nflowchart LR\n subgraph CALL[\"Call site\"]\n A1[\"'Alice'\"]:::cyan\n A2[\"'Wireless Mouse'\"]:::cyan\n A3[\"2\"]:::cyan\n end\n\n subgraph DEF[\"Function parameters\"]\n P1[\"customer\"]:::orange\n P2[\"item\"]:::orange\n P3[\"quantity\"]:::orange\n end\n\n A1 -->|\"position 1\"| P1\n A2 -->|\"position 2\"| P2\n A3 -->|\"position 3\"| P3\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe arrows show the binding. Position 1 in the call goes to position 1 in the definition, and so on. Nothing else affects the wiring.\n\nBecause order is everything, swapping two positional arguments produces silent bugs whenever the types line up. Watch what happens when `quantity` and a price-like number get swapped.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Wireless Mouse\", \"Alice\", 2)\n```\n\n\nNo error. The function ran. The output is nonsense, but Python had no way to know that, because `\"Wireless Mouse\"` and `\"Alice\"` are both strings and the function takes any string for `customer` and `item`. This is the classic argument for using keyword arguments (next section) when a call has more than a few positional values that share a type.\n\nA second classic problem is passing too many positional arguments. Python catches this at call time.\n\n\n```python\ndef apply_discount(price, percent):\n return price * (1 - percent / 100)\n\nprint(apply_discount(99.99, 10, 5))\n```\n\n\nThe error names the count, not the values, because Python doesn't know which of the three you meant to drop. It's your call to figure out which one is extra.\n\nThe mirror of that error, passing too few, gives `missing 1 required positional argument: 'quantity'`. Same idea, opposite direction.\n\n---\n\n# Keyword Arguments\n\nA **keyword argument** binds to a parameter by **name**, not by position. You write `name=value` at the call site, and Python looks up `name` among the parameters and puts `value` there.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"customer={customer}, item={item}, quantity={quantity}\")\n\nplace_order(customer=\"Alice\", item=\"Wireless Mouse\", quantity=2)\n```\n\n\nThe result is identical to the positional version, but the wiring is different. Python isn't counting positions here; it's reading the names. That has two practical consequences.\n\nFirst, **order at the call site stops mattering**. As long as every required parameter gets a value, you can write the keyword arguments in any order you want.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"customer={customer}, item={item}, quantity={quantity}\")\n\nplace_order(quantity=2, item=\"Wireless Mouse\", customer=\"Alice\")\nplace_order(item=\"USB Cable\", customer=\"Bob\", quantity=3)\n```\n\n\nBoth calls produce the right output even though the arguments are written in different orders. Python looks at the names, not the positions.\n\nSecond, **call sites become self-documenting**. If you're reading code that says `place_order(\"Bob\", \"USB Cable\", 3)`, you have to remember the parameter order to know which value means what. If you're reading `place_order(customer=\"Bob\", item=\"USB Cable\", quantity=3)`, no memory is required. The names are right there.\n\nKeyword arguments also turn the silent swap bug from earlier into an explicit one. If you accidentally write `place_order(customer=\"Wireless Mouse\", item=\"Bob\", quantity=2)`, the function still runs (the names match), but the values are obviously wrong when you read the call site, because the parameter names tell you what each value is supposed to be.\n\nThere's one error specific to keyword arguments: passing a keyword that isn't actually a parameter name.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(customer=\"Alice\", product=\"Wireless Mouse\", quantity=2)\n```\n\n\nThe function has a parameter called `item`, not `product`. Python catches the mismatch at call time and tells you exactly which keyword it didn't recognize. The fix is to use the actual parameter name (`item=...`) or to rename the parameter in the function definition if `product` is the better label.\n\n---\n\n# Mixing Positional and Keyword Arguments\n\nPython lets you mix the two styles in a single call, with one rule: **positional arguments come first, keyword arguments come after**. Once you write a keyword argument, every argument after it has to also be a keyword argument.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", quantity=2)\nplace_order(\"Bob\", item=\"USB Cable\", quantity=3)\n```\n\n\nIn the first call, two positional arguments fill `customer` and `item`, then `quantity=2` fills the third slot by name. In the second call, one positional argument fills `customer`, then two keyword arguments fill the rest. Both are fine.\n\nReversing the order isn't fine. A positional argument after a keyword argument is a syntax error, caught before the program even runs.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", item=\"Wireless Mouse\", 2)\n```\n\n\nThe `2` is positional, and it appears after the keyword argument `item=\"Wireless Mouse\"`. Python flags this at parse time, which is why the traceback shows `SyntaxError` instead of `TypeError`. The fix is to either move the `2` before the keyword arguments or to pass it by name as `quantity=2`.\n\nThe other mistake this section introduces is passing the **same parameter twice**, once positionally and once by name. This happens when you mean to add a keyword argument but forget that the same slot is already filled positionally.\n\n\n```python\ndef place_order(customer, item, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2, customer=\"Bob\")\n```\n\n\nThe first positional argument `\"Alice\"` already filled `customer`. The keyword argument `customer=\"Bob\"` tries to fill the same slot again. Python refuses to pick one. This error tends to show up after a refactor where a function's parameter order changes and one call site doesn't get updated cleanly.\n\nA common style guideline (used by many style guides and seen in popular libraries) is: pass the first one or two values positionally when their meaning is obvious from context, and pass the rest by keyword. For `place_order(\"Alice\", item=\"Wireless Mouse\", quantity=2)`, the `customer` is clearly Alice from context, but `item` and `quantity` benefit from the explicit labels. This isn't a hard rule; it's a habit that scales well as functions grow.\n\n---\n\n# Positional-Only Parameters with `/`\n\nSometimes you don't want callers to use keyword syntax for certain parameters. Maybe the parameter name is an implementation detail and you want the freedom to rename it later without breaking anyone's code. Maybe the parameter name is so generic that letting callers reference it by name is just noise. For those cases, Python 3.8 added the `/` marker, which says \"everything before this `/` can only be passed positionally\".\n\n\n```python\ndef apply_discount(price, percent, /):\n return price * (1 - percent / 100)\n\nprint(apply_discount(99.99, 10))\n```\n\n\nThe `/` is not a parameter. It's a marker in the parameter list. Everything to the left of it (`price` and `percent` here) is positional-only. Trying to call this function with keyword syntax fails.\n\n\n```python\ndef apply_discount(price, percent, /):\n return price * (1 - percent / 100)\n\nprint(apply_discount(price=99.99, percent=10))\n```\n\n\nThe error message is specific: positional-only arguments were passed as keywords. The parameter names exist in the source code, but they're not part of the function's public contract. Python's own built-ins lean on this heavily. `len(obj)` is positional-only; you can't call `len(obj=some_list)`. Same for `print` with its first positional values, and many methods on built-in types.\n\nThe shape of a `/`-using signature deserves a small picture. Anything on the left of `/` is locked to positional. Anything on the right behaves normally (positional or keyword, your choice).\n\n\n```mermaid\nflowchart LR\n subgraph SIG[\"def f(a, b, /, c, d):\"]\n L[\"a, b
positional-only\"]:::orange\n SLASH[\"/\"]:::red\n R[\"c, d
positional or keyword\"]:::cyan\n end\n\n L --> SLASH\n SLASH --> R\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe orange box on the left is the positional-only zone; the cyan box on the right is the normal zone. The red `/` is the divider. You can freely choose how to pass the cyan parameters, but the orange ones must come in by position.\n\nHere's a mixed example.\n\n\n```python\ndef place_order(customer, item, /, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2)\nplace_order(\"Alice\", \"Wireless Mouse\", quantity=2)\n```\n\n\nBoth calls work. `customer` and `item` are locked to positional (left of `/`), and `quantity` is free to be either. But this call fails:\n\n\n```python\ndef place_order(customer, item, /, quantity):\n print(f\"{customer} ordered {quantity} x {item}\")\n\nplace_order(customer=\"Alice\", item=\"Wireless Mouse\", quantity=2)\n```\n\n\nThe reasons you'd use `/` in your own code are narrow. The two most common ones: the parameter name is meaningless (\"the value to operate on\", \"the input\"), or you genuinely want the freedom to rename the parameter without breaking callers. For most application code, you won't need it. For library code that exposes a stable API, it's a useful tool.\n\n\n> **INFO**\n>\n> **Cost:** `/` is purely a syntax marker. It has no runtime cost. It just changes which kinds of calls Python accepts.\n\n\n---\n\n# Keyword-Only Parameters with `*`\n\nThe mirror of `/` is `*`. A bare `*` in the parameter list says \"everything after this `*` can only be passed by keyword\". The motivation is the opposite of `/`: instead of hiding a parameter name, you're requiring the caller to use it, because the name carries information that a position wouldn't convey.\n\n\n```python\ndef apply_discount(price, *, percent):\n return price * (1 - percent / 100)\n\nprint(apply_discount(99.99, percent=10))\n```\n\n\nThe first parameter `price` is normal (positional or keyword). The `*` marker comes next. Then `percent`, which is keyword-only because of where it sits. Calling this function with `percent` passed positionally fails.\n\n\n```python\ndef apply_discount(price, *, percent):\n return price * (1 - percent / 100)\n\nprint(apply_discount(99.99, 10))\n```\n\n\nPython's count of \"positional arguments\" only includes the parameters that can be passed positionally. Since `percent` is keyword-only, the function \"takes 1 positional argument\" (just `price`), and passing two positionals is one too many.\n\nThe classic reason to use `*` is to make a function call read clearly when it has a value that would otherwise be a mystery number or boolean. Consider an order placement that takes a flag for whether to send a confirmation email.\n\n\n```python\ndef place_order(customer, item, quantity, *, send_email):\n print(f\"{customer} ordered {quantity} x {item}\")\n if send_email:\n print(f\"Confirmation email sent to {customer}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2, send_email=True)\n```\n\n\nWithout `*`, a caller could write `place_order(\"Alice\", \"Wireless Mouse\", 2, True)`. The reader has to look up the function to find out what that trailing `True` means. With `*`, the only way to write the call is `send_email=True`, and the meaning is right there. This pattern is common in library APIs: any boolean flag or rarely-used option tends to be keyword-only.\n\nThere's a second, more practical reason: if you reorder or insert keyword-only parameters later, no caller breaks. Positional callers care about order; keyword callers don't. Locking a parameter to keyword-only is a small commitment that buys you flexibility for the lifetime of the function.\n\n\n```mermaid\nflowchart LR\n subgraph SIG[\"def f(a, b, *, c, d):\"]\n L[\"a, b
positional or keyword\"]:::cyan\n STAR[\"*\"]:::red\n R[\"c, d
keyword-only\"]:::orange\n end\n\n L --> STAR\n STAR --> R\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe cyan zone on the left is flexible; the orange zone on the right is locked to keyword. The red `*` is the marker.\n\nA note on the bare `*` versus `*args`: `*args` is a star followed by a parameter name and it collects any extra positional arguments. The bare `*` here has no name, collects nothing, and only acts as a divider. Same character, different role.\n\n---\n\n# Combining `/` and `*` in One Signature\n\n`/` and `*` can appear in the same parameter list, and when they do they carve the parameters into three zones: positional-only on the left of `/`, normal (positional or keyword) in the middle, and keyword-only on the right of `*`.\n\n\n```python\ndef place_order(customer, item, /, quantity, *, send_email):\n print(f\"{customer} ordered {quantity} x {item}, send_email={send_email}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2, send_email=True)\nplace_order(\"Alice\", \"Wireless Mouse\", quantity=2, send_email=False)\n```\n\n\n`customer` and `item` are positional-only (left of `/`). `quantity` is in the middle zone and can be either. `send_email` is keyword-only (right of `*`).\n\n\n```mermaid\nflowchart LR\n subgraph SIG[\"def place_order(customer, item, /, quantity, *, send_email):\"]\n PO[\"customer, item
positional-only\"]:::orange\n SLASH[\"/\"]:::red\n MID[\"quantity
positional or keyword\"]:::cyan\n STAR[\"*\"]:::red\n KO[\"send_email
keyword-only\"]:::teal\n end\n\n PO --> SLASH\n SLASH --> MID\n MID --> STAR\n STAR --> KO\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThree zones, two markers. The orange zone is locked to positional, the teal zone is locked to keyword, and the cyan zone in the middle accepts either style. This is the complete picture of how a parameter list is shaped in modern Python.\n\nIf you try to pass a positional-only parameter as a keyword, you get the error from the `/` section. If you try to pass a keyword-only parameter as a positional, you get the error from the `*` section. Both rules apply to the same call, separately.\n\n\n```python\ndef place_order(customer, item, /, quantity, *, send_email):\n print(f\"{customer} ordered {quantity} x {item}, send_email={send_email}\")\n\nplace_order(customer=\"Alice\", item=\"Wireless Mouse\", quantity=2, send_email=True)\n```\n\n\nTwo of the four arguments (`customer` and `item`) are in the positional-only zone, and the call tried to pass them as keywords. The error names exactly those two.\n\n\n```python\ndef place_order(customer, item, /, quantity, *, send_email):\n print(f\"{customer} ordered {quantity} x {item}, send_email={send_email}\")\n\nplace_order(\"Alice\", \"Wireless Mouse\", 2, True)\n```\n\n\nThe function has three positional-friendly parameters (`customer`, `item`, `quantity`), and the call passed four positional values. The fourth would have to be a keyword argument, because `send_email` is keyword-only.\n\nYou won't reach for this combined shape often in everyday code. Most application functions get by with normal parameters. The pattern shows up in library APIs where the author wants to lock down the public contract precisely. When you do see it, the rule to remember is: `/` says \"stop using names here\", `*` says \"start using names here\", and anything between them gets to choose.\n\n---\n\n# Common Errors Reference\n\nThe errors you've seen scattered through this lesson are the four you'll meet most often. They're worth seeing side by side, with the exact wording Python uses, because the wording tells you which rule was broken.\n\n\n| What you did wrong | Error you'll see |\n| --- | --- |\n| Forgot a required argument | `TypeError: f() missing 1 required positional argument: 'x'` |\n| Passed too many positional arguments | `TypeError: f() takes N positional arguments but M were given` |\n| Used a keyword that isn't a parameter | `TypeError: f() got an unexpected keyword argument 'x'` |\n| Filled the same slot twice | `TypeError: f() got multiple values for argument 'x'` |\n| Wrote positional after keyword | `SyntaxError: positional argument follows keyword argument` |\n| Used keyword for a positional-only parameter | `TypeError: f() got some positional-only arguments passed as keyword: 'x'` |\n\n\nThe first four are runtime errors (`TypeError`): Python notices them when the call actually happens. The fifth is a parse-time error (`SyntaxError`): Python rejects the source file before any code runs. The sixth is a runtime error specific to `/`.\n\nWhen you see one of these in a traceback, the recipe is the same every time:\n\n1. Read the function's `def` line.\n2. Read your call site.\n3. Match them up parameter by parameter, in order, then by name.\n4. The mismatch the error names is where the gap is.\n\nThis is more useful than it sounds. Most of the time the fix is obvious once you've actually compared the two sides; the error message just nudges you to do that comparison.","pageType":"python"}

Function Parameters

Get Premium