{"title":"Functions Basics","description":"","content":"A function is a named block of code that you can run as many times as you want by referring to its name. Once a function exists, the rest of your program can lean on it without caring how it works inside, which is the smallest, most useful form of abstraction Python gives you. This lesson covers what a function is, how to define one with `def`, how to call it, and the conventions around naming.\n\n---\n\n# Why Functions Exist\n\nCode that lives at the top level of a file runs once, top to bottom, in the order it appears. That works for a handful of lines, but the moment you need to do the same thing twice, you have a choice: copy the lines, or wrap them in a function and call the function twice.\n\nConsider a small e-commerce script that prints a welcome banner before showing the cart, then again before showing the order summary. Without functions, the printing logic gets duplicated:\n\n\n```python\nprint(\"=\" * 40)\nprint(\"Welcome to AlgoMaster Store\")\nprint(\"=\" * 40)\n\n# ... show cart items here ...\n\nprint(\"=\" * 40)\nprint(\"Welcome to AlgoMaster Store\")\nprint(\"=\" * 40)\n\n# ... show order summary here ...\n```\n\n\nSix lines do one job that should be one line of intent. If the store name changes, you have to find every copy. If you want to add an extra line to the banner, you have to add it in both places. The duplication is the bug waiting to happen.\n\nA function fixes both problems:\n\n\n```python\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n\nshow_welcome_banner()\n# ... show cart items here ...\nshow_welcome_banner()\n# ... show order summary here ...\n```\n\n\nThe three printing lines now live in one place, behind the name `show_welcome_banner`. The rest of the program asks for the banner by name and doesn't care how it's drawn. If the banner ever changes, you change it once.\n\nThat's the first reason to write a function: **reuse**. The second reason is just as important: **naming**. The line `show_welcome_banner()` reads in plain English. Anyone scanning the file can tell what's happening without parsing three `print` calls. Even if you only call a function once, giving a stretch of code a name is often worth it on its own.\n\nFunctions also separate **what** from **how**. The caller knows what `show_welcome_banner` does (it shows a welcome banner) and doesn't need to know how it does it (three prints with equals signs). That separation is what lets you change the inside of a function later without breaking the rest of the program.\n\n---\n\n# Defining a Function With `def`\n\nPython uses the `def` keyword to define a function. The shape is fixed: the keyword, the function name, parentheses, a colon, and then an indented body. Every function you write follows this skeleton.\n\n\n```python\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n```\n\n\nSix things to notice in those four lines.\n\n1. `def` is the keyword that starts a function definition. It tells Python \"the next thing is a new function\".\n2. `show_welcome_banner` is the function's name. You'll use this name later to call it.\n3. `()` is the empty parameter list. This function takes no inputs, but the parentheses are still required.\n4. `:` ends the header. The colon is what tells Python \"the body starts now\".\n5. The body is indented. Python uses indentation, not braces, to mark which lines belong to the function. Four spaces is the standard.\n6. The body has three statements. They run together, in order, every time the function is called.\n\nThe body can be any valid Python: prints, assignments, loops, conditionals, calls to other functions, anything. The only rule is that it has to be indented under the header. The function ends at the first line that's no longer indented.\n\n\n```python\ndef display_cart_header():\n print(\"Your Cart\")\n print(\"---------\")\n\nprint(\"This line is not in the function.\")\n```\n\n\nTwo lines belong to `display_cart_header` because they're indented. The third `print` is back at the top level, so it's outside the function. Notice the output: only the top-level line ran. Defining a function does not run it. That's the next thing to cover.\n\n\n```mermaid\nflowchart LR\n Header[\"def show_welcome_banner():\"]:::cyan\n Body1[\" print(...)\"]:::orange\n Body2[\" print(...)\"]:::orange\n Body3[\" print(...)\"]:::orange\n After[\"next_line at column 0
not part of function\"]:::teal\n\n Header --> Body1 --> Body2 --> Body3 --> After\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe cyan box is the header, the orange boxes are the indented body, and the teal box is the first line that ends the function (because it's back at column zero). Python uses indentation alone to decide where the function stops.\n\nIf you forget the colon at the end of the header, Python raises a `SyntaxError` before the program runs:\n\n\n```python\ndef show_welcome_banner()\n print(\"Welcome to AlgoMaster Store\")\n```\n\n\nThe error points right at the spot where the colon should be. Python won't even try to run the file until you fix it. The same kind of error fires if you forget the parentheses, or if you indent the body wrong.\n\n---\n\n# Calling a Function\n\nDefining a function tells Python \"here's a recipe\". Calling a function tells Python \"follow that recipe right now\". The two are completely separate steps, and beginners often confuse them.\n\nTo call a function, write its name followed by parentheses:\n\n\n```python\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n\nshow_welcome_banner()\n```\n\n\nThe first four lines define the function. Nothing prints when those lines run; Python just registers the name `show_welcome_banner` and remembers the body. The fifth line, `show_welcome_banner()`, is the call. That's when the body actually runs.\n\nThe parentheses are what make it a call. Without them, you're just referring to the function as a value, not asking Python to run it.\n\n\n```python\ndef show_welcome_banner():\n print(\"Welcome to AlgoMaster Store\")\n\n# This does NOT call the function.\nshow_welcome_banner\n\n# This calls the function.\nshow_welcome_banner()\n```\n\n\nThe line `show_welcome_banner` (no parentheses) is a valid Python expression. It produces the function object, but Python doesn't do anything with it, so nothing happens. The next line, `show_welcome_banner()`, has the parentheses, so Python runs the body.\n\nYou can call the same function as many times as you want, in any order, from anywhere in your code (as long as it's defined first).\n\n\n```python\ndef show_welcome_banner():\n print(\"Welcome to AlgoMaster Store\")\n\nshow_welcome_banner()\nshow_welcome_banner()\nshow_welcome_banner()\n```\n\n\nEach call runs the body independently. The function doesn't \"remember\" that it ran before; every call starts fresh.\n\nOne small thing about ordering: Python reads the file top to bottom, so the `def` has to appear before the call. Calling a function that hasn't been defined yet is a `NameError`:\n\n\n```python\nshow_welcome_banner()\n\ndef show_welcome_banner():\n print(\"Welcome to AlgoMaster Store\")\n```\n\n\nBy the time Python reaches the first line, it hasn't seen the `def` yet, so the name `show_welcome_banner` doesn't exist. The fix is just to put the `def` before the call.\n\n\n```mermaid\nflowchart LR\n Caller[\"caller code\"]:::cyan\n Call[\"show_welcome_banner()\"]:::orange\n Body[\"function body runs
top to bottom\"]:::green\n Return[\"control returns
to caller\"]:::teal\n Next[\"next line
after the call\"]:::cyan\n\n Caller --> Call --> Body --> Return --> Next\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```\n\n\nThis is the call cycle: the caller hits a call, Python jumps into the function body, runs it to completion, and then comes back to the line right after the call. Anything you write below the call won't run until the function finishes. For a function with three prints, that's nearly instant. For a function that does heavy work, it could take a while, but the rule is the same.\n\n---\n\n# Defining vs Calling: The Difference That Trips People Up\n\nDefining a function and calling a function are two separate events, often pages apart in real code. The `def` block sets up the recipe. The call runs it. Mixing these up is one of the first stumbles new Python programmers hit.\n\nA definition runs once, when Python reaches the `def` line. It doesn't execute the body; it just files the body away under the function's name. A call can happen zero, one, or many times after that, and each call runs the body again.\n\n\n```python\nprint(\"before def\")\n\ndef greet_customer():\n print(\"Hello, valued customer!\")\n\nprint(\"after def, before call\")\n\ngreet_customer()\n\nprint(\"after call\")\n```\n\n\nRead the output in order. The two top-level prints around the `def` run as Python passes through them. The `def` itself doesn't print anything, so there's no output for it. Then `greet_customer()` runs the body, which prints the greeting. Then the last top-level print runs. The function's body printed exactly once because we called it exactly once.\n\nIf you define a function but never call it, the body simply never runs:\n\n\n```python\ndef print_order_confirmation():\n print(\"Your order has been placed.\")\n print(\"You'll get a confirmation email shortly.\")\n\nprint(\"script done\")\n```\n\n\n`print_order_confirmation` is defined, but no line in the script calls it. The two prints inside the body produce nothing. Python knows the function exists (you could call it from the REPL after the script finishes if you imported it), but on its own a definition is silent.\n\nThe opposite mistake also happens: people put a call where they meant to put a definition, or vice versa. A common version is calling the function inside its own definition by accident:\n\n\n```python\ndef show_welcome_banner():\n show_welcome_banner()\n```\n\n\nThis is a recursive function with no base case, which is a separate topic. The point for now is that the syntax is legal even though the behavior is broken. Python doesn't stop you from writing code that calls a function from inside its own body. Recursion is covered in a much later chapter; until then, keep function bodies free of calls to themselves.\n\nThe mental model that helps the most is this: think of `def` as \"save this recipe under this name\" and the call as \"cook the recipe now\". The recipe can sit on the shelf forever. Cooking it requires explicitly grabbing it and going.\n\n---\n\n# Functions Without Return Values\n\nSome functions exist purely to do something: print a banner, write a file, log a message. They don't hand a value back to the caller. The function bodies we've seen so far are all in this group: they call `print`, but they don't produce a result you can store in a variable.\n\nIn Python, every function returns something. If you don't say what, the function returns `None`. That's the special value Python uses to mean \"nothing of interest here\". It's a value, but it's the kind of value you generally don't do anything with.\n\n\n```python\ndef greet_customer():\n print(\"Hello, valued customer!\")\n\nresult = greet_customer()\nprint(result)\n```\n\n\nThe function body printed its greeting and stopped. The call expression `greet_customer()` produced `None`, which we stored in `result`. Printing `result` shows the word `None`, which is Python's way of saying \"the function didn't have a meaningful answer\".\n\nYou don't normally write code that captures the return of a print-only function. The example above is just to show what's there. In practice, you'd write the call as a statement on its own line:\n\n\n```python\ndef display_cart_header():\n print(\"Your Cart\")\n print(\"---------\")\n\ndisplay_cart_header()\n```\n\n\nNo assignment, no use of the return value, just \"do the thing\". This style is fine and very common. Functions that exist for their side effects (printing, writing, modifying something) are sometimes called **procedures** in other languages, but in Python they're just functions that happen to return `None`.\n\nThe `return` statement is what you use when you want a function to produce a value the caller can use. For now, two things to remember:\n\n1. A function without a `return` returns `None`.\n2. The keyword `return` exists for producing values.\n\nUntil then, the functions in this lesson will do their work through `print`.\n\n---\n\n# Naming Functions\n\nA function name is just an identifier, the same kind of name you'd use for a variable. The same rules apply: it must start with a letter or underscore, can contain letters, digits, and underscores, and can't be a Python keyword. But the conventions are different from variables in a few subtle ways.\n\nThe most important convention is **snake_case**: lowercase words separated by underscores. Python's official style guide, PEP 8, recommends this for both function names and variable names, and the standard library uses it everywhere.\n\n\n```python\n# Good: snake_case\ndef show_welcome_banner():\n print(\"Welcome\")\n\ndef display_cart_header():\n print(\"Your Cart\")\n\ndef print_order_confirmation():\n print(\"Order placed\")\n```\n\n\nThese names read naturally and tell you what each function does at a glance. Compare them to less helpful styles:\n\n\n```python\n# Less clear, even if the syntax is legal.\ndef ShowWelcomeBanner():\n print(\"Welcome\")\n\ndef showwelcomebanner():\n print(\"Welcome\")\n\ndef swb():\n print(\"Welcome\")\n\ndef doStuff():\n print(\"Welcome\")\n```\n\n\n`ShowWelcomeBanner` uses PascalCase, which Python reserves for class names. Mixing it into function names confuses readers who expect the convention. `showwelcomebanner` is technically valid but hard to read because the words run together. `swb` is short but tells you nothing. `doStuff` is camelCase (more common in JavaScript) and vague to boot. None of these are illegal; they just go against the grain of how Python code is normally written.\n\nA good function name is **a verb phrase that describes what the function does**. Functions act, so their names should reflect action.\n\n\n| Pattern | Examples |\n| --- | --- |\n| `verb_object` | `show_banner`, `print_total`, `send_email`, `clear_cart` |\n| `verb_for_object` | `total_for_cart`, `tax_for_order`, `discount_for_customer` |\n| `is_/has_` (predicates) | `is_empty`, `has_discount`, `is_in_stock` |\n| `get_` for retrieval | `get_customer_email`, `get_cart_total` |\n\n\nThe shape of the name should hint at what kind of work the function does. Boolean-returning functions (yes/no questions) usually start with `is_` or `has_`. Functions that produce a value usually start with `get_`, `compute_`, `calculate_`, or use a noun-phrase like `cart_total`. Functions that just do something with no useful return often start with a plain verb: `print_`, `show_`, `display_`, `save_`, `send_`.\n\n\n```python\ndef greet_customer():\n print(\"Hello, valued customer!\")\n\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n\ndef display_cart_header():\n print(\"Your Cart\")\n print(\"---------\")\n\ngreet_customer()\nshow_welcome_banner()\ndisplay_cart_header()\n```\n\n\nEach name reads like a description of what's about to happen. The calling code is essentially a list of small, named actions. That's the kind of code that's pleasant to come back to a month later, because the names do most of the explaining.\n\nA few practical rules of thumb for naming:\n\n- Prefer clarity over brevity. `print_order_confirmation` is better than `poc`.\n- Don't shadow built-ins. Naming a function `list` or `sum` or `print` will hide the built-in of the same name, which causes weird bugs later.\n- Don't reuse the same name for very different things. If `process_order` does three different things in different files, readers can't trust the name.\n- One thing per function. If a function name needs the word `and` in it (`save_and_email_receipt`), it's probably doing two things; split it.\n\nOne forward note: Python lets you attach a short description called a **docstring** to a function, written as a string literal on the first line of the body. Docstrings are how you document what a function does, what its parameters mean, and what it returns. Good names plus a one-line docstring carry a lot of weight.\n\n---\n\n# Where Functions Live\n\nA function definition has to appear somewhere in your code. The most common place is at the **module level**: directly inside a `.py` file, not indented under anything else. Functions defined at the module level can be called from anywhere in that file (below their `def`), and they're what other files import when they do `from yourfile import some_function`.\n\n\n```python\n# This is a module-level function: defined at column 0.\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n\n# This is also at the module level, just a call.\nshow_welcome_banner()\n```\n\n\nThe `def` line starts at column 0, and the body is indented one level. That makes `show_welcome_banner` a module-level function. Most functions you write will live here.\n\nPython also lets you define a function **inside** another function. That's called a **nested function** (or sometimes an inner function), and it's a real feature, not a syntax accident.\n\n\n```python\ndef show_order_summary():\n def print_divider():\n print(\"-\" * 30)\n\n print_divider()\n print(\"Order #12345\")\n print_divider()\n\nshow_order_summary()\n```\n\n\n`print_divider` is defined inside `show_order_summary`. Outside the outer function, the name `print_divider` doesn't exist; it's only meaningful while `show_order_summary` is running. Each time `show_order_summary` is called, Python re-creates the nested function.\n\nNested functions are useful for a few specific things: hiding a helper that's only relevant to one outer function, capturing values from the surrounding scope (called a **closure**), and a handful of patterns around decorators and callbacks. The point for now is that nested functions are legal Python, and you'll see them in real codebases.\n\nDon't reach for nested functions in your first programs. Module-level functions are the default for a reason: they're easier to read, easier to test in isolation, and easier to reuse from other parts of your code. A function buried inside another function is harder to find and harder to call from outside. Use them when there's a clear reason; otherwise, keep your `def` lines at column 0.\n\nA small rule of thumb: if a helper function is only ever called from one other function, and the body is short, a nested definition can be cleaner. If the helper might be useful elsewhere, define it at the module level so other callers can reach it too.\n\n\n```mermaid\nflowchart TD\n File[\"my_script.py\"]:::cyan\n Mod1[\"def show_welcome_banner():
module-level\"]:::orange\n Mod2[\"def show_order_summary():
module-level\"]:::orange\n Nested[\"def print_divider():
nested inside
show_order_summary\"]:::teal\n Calls[\"show_welcome_banner()
show_order_summary()
module-level calls\"]:::green\n\n File --> Mod1\n File --> Mod2\n Mod2 --> Nested\n File --> Calls\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows the layout: the file (cyan) holds two module-level functions (orange) and the top-level calls (green). One of those module-level functions has a nested helper (teal) that lives only inside it. From outside the file, you can import the two module-level functions, but not the nested one.\n\n---\n\n# A Slightly Bigger Example\n\nPutting the ideas above together, here's a small e-commerce script that uses several small functions to print a tidy order summary. None of the functions take parameters or return values; they just do their part and finish.\n\n\n```python\ndef show_welcome_banner():\n print(\"=\" * 40)\n print(\"Welcome to AlgoMaster Store\")\n print(\"=\" * 40)\n\ndef display_cart_header():\n print()\n print(\"Your Cart\")\n print(\"---------\")\n\ndef display_cart_items():\n print(\"Wireless Mouse $29.99\")\n print(\"USB Cable $4.99\")\n print(\"HDMI Cable $14.99\")\n\ndef print_order_confirmation():\n print()\n print(\"Order placed.\")\n print(\"Confirmation email sent to your inbox.\")\n\nshow_welcome_banner()\ndisplay_cart_header()\ndisplay_cart_items()\nprint_order_confirmation()\n```\n\n\nThe four `def` blocks come first. None of them run when defined; Python just registers the four names. Then four calls produce the full output, one piece at a time. The script as a whole reads like an outline of the page: banner, cart header, cart items, confirmation. Each function name is a label for its piece.\n\nThe thing this example can't yet handle is **variation**. Every call produces the same output, because the functions have no way to receive data from the caller. `display_cart_items` always prints the same three lines, even if the cart is different. To make these functions useful for real carts, real customers, and real orders, we need a way to feed information into them. That's what parameters are for.\n\n---\n\n# Quiz","pageType":"python"}

Functions Basics

Get Premium