{"title":"return Statement","description":"","content":"A function that doesn't return anything can only talk to the outside world through side effects: prints, file writes, mutations of objects it was handed. That's fine for some jobs, but the moment you want to use a function's result in a larger expression, store it for later, or test it, you need a real return value. This lesson covers the `return` statement, what happens when you leave it out, how to return more than one value, when an early return makes a function easier to read, and why returning a value is different from printing one.\n\n---\n\n# The `return` Statement\n\n`return` does two things at once. It hands a value back to whoever called the function, and it ends the function immediately. Any code after `return` in the same execution path never runs.\n\n\n```python\ndef compute_total(cart):\n total = 0.0\n for price in cart:\n total += price\n return total\n\ncart = [29.99, 14.99, 9.99]\nresult = compute_total(cart)\nprint(result)\nprint(f\"Cart total: ${result:.2f}\")\n```\n\n\nThe function builds up `total`, returns it, and the caller stores it in `result`. From that point, `result` is an ordinary `float` you can do arithmetic on, format, pass to another function, or anything else. The function itself is done; its local variable `total` is gone.\n\nThe value after `return` can be any expression. Python evaluates it and hands back the result.\n\n\n```python\ndef compute_total(cart):\n return sum(cart)\n\nprint(compute_total([29.99, 14.99, 9.99]))\nprint(compute_total([]))\n```\n\n\n`sum(cart)` is evaluated first, then its result is returned. The function has one expression in its body, which is a perfectly normal shape for a small function. Note that `sum([])` returns `0` (an integer), not `0.0`, because that's how the built-in `sum` is defined.\n\nOnce `return` runs, the function is over. Anything below it in the same path is dead code.\n\n\n```python\ndef apply_discount(price, discount_percent):\n discounted = price * (1 - discount_percent / 100)\n return discounted\n print(\"this line never runs\")\n\nprint(apply_discount(100, 10))\n```\n\n\nThe `print` after `return` is never reached. Python won't warn you about it; it just sits there as a footnote in the source code. Most linters will flag it as unreachable code, which is one reason to run a linter on anything beyond a quick script.\n\nA `return` with no expression returns `None`. That's a deliberate way to say \"I'm done, and there's no useful value to hand back.\"\n\n\n```python\ndef cancel_order(order_id, orders):\n if order_id not in orders:\n return\n orders[order_id][\"status\"] = \"cancelled\"\n\norders = {\"ORD-1001\": {\"status\": \"placed\"}}\nresult = cancel_order(\"ORD-1001\", orders)\nprint(result)\nprint(orders[\"ORD-1001\"])\n```\n\n\nThe bare `return` at the top of the function is an early exit. The function's main job is to mutate `orders`, not to compute a value, so handing back `None` is honest. The caller can ignore it.\n\n---\n\n# Implicit `None`: When You Forget to Return\n\nA function that finishes without hitting any `return` statement quietly returns `None`. There's no warning, no error, and no syntax difference between \"I meant to return nothing\" and \"I forgot a return\". The runtime treats both the same.\n\n\n```python\ndef compute_total(cart):\n total = 0.0\n for price in cart:\n total += price\n # forgot to return\n\nresult = compute_total([29.99, 14.99])\nprint(result)\nprint(type(result))\n```\n\n\nThe function did all the work of summing the cart, then threw the answer away by not returning it. The caller gets `None` because that's what every function returns when execution falls off the end without a `return`.\n\nThe most common version of this bug is when you mix up `print` and `return`. Code that \"looks right\" prints the answer but doesn't return it, and the caller stores `None`.\n\n**What's wrong with this code?**\n\n\n```python\ndef compute_total(cart):\n total = sum(cart)\n print(total)\n\ncart_total = compute_total([29.99, 14.99, 9.99])\ntax = cart_total * 0.08\nprint(f\"Tax: ${tax:.2f}\")\n```\n\n\nThe function prints `54.97`, which is misleading because it makes the function look like it's \"working\". But `compute_total` returns `None`, so `cart_total` is `None`, and the multiplication on the next line blows up. The fix is to swap `print` for `return`:\n\n**Fix:**\n\n\n```python\ndef compute_total(cart):\n total = sum(cart)\n return total\n\ncart_total = compute_total([29.99, 14.99, 9.99])\ntax = cart_total * 0.08\nprint(f\"Cart total: ${cart_total:.2f}\")\nprint(f\"Tax: ${tax:.2f}\")\n```\n\n\nNow the caller actually has a number to work with. The function can still print for debugging if you want, but the meaningful output has to leave the function through `return`.\n\nA subtler version of the same mistake is chaining `print` around a function call. `print(some_function())` calls the function, then prints whatever it returned. If the function already printed inside itself, you'll see the value once from the inner print and then `None` from the outer one. The fix is the same: decide whether the function's job is to print or to return, and don't do both.\n\n\n> **INFO**\n>\n> **Cost:** Forgetting `return` is the single most common cause of \"my function returns `None` for no reason\" questions. When debugging, the first check is always: does the function have a `return` statement on every path you care about?\n\n\n---\n\n# Returning Multiple Values\n\nA function can hand back more than one value by separating them with commas. Under the hood, Python builds a tuple and returns that, but the syntax makes it feel like you're returning multiple things directly.\n\n\n```python\ndef compute_totals(cart, discount_rate, tax_rate):\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n after_discount = subtotal - discount\n tax = after_discount * tax_rate\n total = after_discount + tax\n return subtotal, discount, tax, total\n\nresult = compute_totals([29.99, 14.99, 9.99], 0.1, 0.08)\nprint(result)\nprint(type(result))\n```\n\n\nThe `return subtotal, discount, tax, total` line is shorthand for `return (subtotal, discount, tax, total)`. The parentheses are optional in this position. Either way, the function returns a single tuple, and the caller has one value to handle.\n\nThe caller usually unpacks the tuple immediately, which is what makes \"multiple return values\" feel real. Unpacking matches the names on the left to the positions on the right:\n\n\n```python\ndef compute_totals(cart, discount_rate, tax_rate):\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n after_discount = subtotal - discount\n tax = after_discount * tax_rate\n total = after_discount + tax\n return subtotal, discount, tax, total\n\nsubtotal, discount, tax, total = compute_totals([29.99, 14.99, 9.99], 0.1, 0.08)\nprint(f\"Subtotal: ${subtotal:.2f}\")\nprint(f\"Discount: ${discount:.2f}\")\nprint(f\"Tax: ${tax:.2f}\")\nprint(f\"Total: ${total:.2f}\")\n```\n\n\nFour names on the left, four values in the returned tuple, matched by position. The function reads as if it returned four named values, even though the underlying mechanism is one tuple.\n\n\n```mermaid\nflowchart LR\n Call[\"compute_totals(cart, 0.1, 0.08)\"]:::cyan\n Build[\"return subtotal, discount,
tax, total\"]:::orange\n Tuple[\"(54.97, 5.50,
3.96, 53.43)\"]:::teal\n Unpack[\"subtotal, discount,
tax, total = ...\"]:::orange\n S[\"subtotal = 54.97\"]:::green\n D[\"discount = 5.50\"]:::green\n T[\"tax = 3.96\"]:::green\n G[\"total = 53.43\"]:::green\n\n Call --> Build\n Build --> Tuple\n Tuple --> Unpack\n Unpack --> S\n Unpack --> D\n Unpack --> T\n Unpack --> G\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 box is the call. The orange step is where Python packs the four values into a single tuple (the teal box) before handing it back. On the caller side, the assignment with four names unpacks that tuple into four green variables. The \"tuple in the middle\" is invisible when you write code, but it's the actual mechanism, and knowing it explains every behavior in this section.\n\nThe number of names on the left has to match the number of values in the tuple, or you get a `ValueError`.\n\n\n```python\ndef compute_totals(cart, discount_rate, tax_rate):\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n after_discount = subtotal - discount\n tax = after_discount * tax_rate\n total = after_discount + tax\n return subtotal, discount, tax, total\n\nsubtotal, discount, total = compute_totals([29.99, 14.99, 9.99], 0.1, 0.08)\n```\n\n\nFour values came back, three names tried to catch them. Python won't drop the extras silently. If you genuinely only care about some of the values, the convention is to use `_` (a single underscore) as the name for ones you want to throw away:\n\n\n```python\ndef compute_totals(cart, discount_rate, tax_rate):\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n after_discount = subtotal - discount\n tax = after_discount * tax_rate\n total = after_discount + tax\n return subtotal, discount, tax, total\n\n# Only interested in subtotal and total.\nsubtotal, _, _, total = compute_totals([29.99, 14.99, 9.99], 0.1, 0.08)\nprint(f\"Subtotal: ${subtotal:.2f}, Total: ${total:.2f}\")\n```\n\n\nThe underscore is just a regular variable name; it has no special meaning to Python. The convention is \"I'm not going to use this\", which is enough of a signal for readers and many editors will dim the line accordingly.\n\nYou can also accept the whole tuple without unpacking and index into it (`result[0]`, `result[-1]`), which is useful when you want to pass the bundle along. The unpacking form is clearer when callers use all the values; the indexing form is fine for one or two reads.\n\n\n> **INFO**\n>\n> **Cost:** A returned tuple is one object, allocated once per call. There's no per-element overhead beyond that. Worrying about the cost of returning multiple values is almost always premature; the readability win of named, unpacked results is worth far more.\n\n\nA common pattern in real code is a \"lookup that might fail\", returning both the result and a found/not-found flag:\n\n\n```python\ndef lookup_product(catalog, name):\n for product in catalog:\n if product[\"name\"] == name:\n return product, True\n return None, False\n\ncatalog = [\n {\"name\": \"Wireless Mouse\", \"price\": 29.99},\n {\"name\": \"USB Cable\", \"price\": 4.99},\n {\"name\": \"HDMI Cable\", \"price\": 14.99},\n]\n\nproduct, found = lookup_product(catalog, \"USB Cable\")\nprint(found, product)\n\nproduct, found = lookup_product(catalog, \"Monitor\")\nprint(found, product)\n```\n\n\nTwo return paths, both returning a `(product, found)` pair. The caller always unpacks the same way, then branches on `found`. This is one of those shapes you'll see often once you start looking for it.\n\n---\n\n# Early Return: Guard Clauses\n\nA function with one return at the end is a common shape, but it isn't the only one. **Early return** (also called a \"guard clause\") is a `return` that fires at the top of a function for an edge case, so the rest of the function can focus on the normal path.\n\nThe motivating example is a function with several special cases nested in `if`/`else`. Without early returns, the indentation grows:\n\n\n```python\ndef compute_cart_total(cart, discount_rate):\n if cart is not None:\n if len(cart) > 0:\n if 0 <= discount_rate <= 1:\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n total = subtotal - discount\n return total\n else:\n return 0.0\n else:\n return 0.0\n else:\n return 0.0\n```\n\n\nThe interesting work is at the bottom of a four-deep pyramid. With early returns, each edge case gets handled at the top and the main logic stays at the outermost level:\n\n\n```python\ndef compute_cart_total(cart, discount_rate):\n if cart is None:\n return 0.0\n if len(cart) == 0:\n return 0.0\n if not (0 <= discount_rate <= 1):\n return 0.0\n\n subtotal = sum(cart)\n discount = subtotal * discount_rate\n return subtotal - discount\n\nprint(compute_cart_total(None, 0.1))\nprint(compute_cart_total([], 0.1))\nprint(compute_cart_total([29.99, 14.99], 1.5))\nprint(compute_cart_total([29.99, 14.99], 0.1))\n```\n\n\nThree guard clauses at the top, each handling one edge case. The actual logic at the bottom doesn't need any `if`. The reader can see at a glance \"this function handles three special cases and then does the math\".\n\nThe pattern reads naturally in plain English: \"If the cart is missing, the total is zero. If the cart is empty, the total is zero. If the discount is out of range, the total is zero. Otherwise, here's the math.\" Each sentence is one guard clause.\n\n\n```mermaid\nflowchart TD\n Start[\"compute_cart_total(cart, rate)\"]:::cyan\n Q1{\"cart is None?\"}:::orange\n R1[\"return 0.0\"]:::red\n Q2{\"len(cart) == 0?\"}:::orange\n R2[\"return 0.0\"]:::red\n Q3{\"rate out of range?\"}:::orange\n R3[\"return 0.0\"]:::red\n Main[\"subtotal = sum(cart)
discount = subtotal * rate
return subtotal - discount\"]:::green\n End[\"caller receives total\"]:::teal\n\n Start --> Q1\n Q1 -->|\"yes\"| R1\n Q1 -->|\"no\"| Q2\n Q2 -->|\"yes\"| R2\n Q2 -->|\"no\"| Q3\n Q3 -->|\"yes\"| R3\n Q3 -->|\"no\"| Main\n R1 --> End\n R2 --> End\n R3 --> End\n Main --> End\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\nEach diamond is one guard. Every \"yes\" branch leads straight out of the function with a small return value. Every \"no\" branch falls through to the next check, and eventually to the main computation. The shape is wide and shallow, not deep and nested.\n\nGuard clauses work well when:\n\n- There are several short, unrelated reasons to bail out.\n- Each edge case has an obvious \"default\" answer (`0`, `None`, `False`, an empty list).\n- The main logic only makes sense once the edge cases are out of the way.\n\nThey work less well when:\n\n- All paths share post-processing (logging, building a response object) that you don't want to duplicate at every return site.\n- The function only has one or two simple branches; an `if`/`else` reads just as well.\n\nEmpty-cart is the textbook E-Commerce example. Many small functions in checkout code start with `if not cart: return 0`. The rest of the function gets to assume there's something to work on.\n\n\n```python\ndef cart_summary(cart):\n if not cart:\n return \"Your cart is empty.\"\n\n item_count = len(cart)\n total = sum(item[\"price\"] * item[\"quantity\"] for item in cart)\n return f\"{item_count} items, total ${total:.2f}\"\n\nprint(cart_summary([]))\nprint(cart_summary([\n {\"name\": \"Wireless Mouse\", \"price\": 29.99, \"quantity\": 2},\n {\"name\": \"USB Cable\", \"price\": 4.99, \"quantity\": 3},\n]))\n```\n\n\nThe empty-cart guard is the first line. Below it, the function gets to assume `cart` has at least one item. No `if cart: ...` wrapping the rest of the body, no extra indentation. The reader sees \"if empty, bail; otherwise, summarize\".\n\n---\n\n# Multiple Returns vs Single Return\n\nA long-running style debate in programming is whether functions should have exactly one `return` (single-exit) or many (multiple-exit, including guard clauses). Both work, both produce correct programs, and both have fans. Knowing the trade-offs lets you pick the right one for the function in front of you.\n\n**Multiple returns** scatter the exits throughout the function, usually as guard clauses and early matches.\n\n\n```python\ndef validate_coupon(code, valid_codes, expired_codes):\n if code is None or code == \"\":\n return False\n if code in expired_codes:\n return False\n if code in valid_codes:\n return True\n return False\n\nvalid = {\"SUMMER10\", \"WELCOME\"}\nexpired = {\"SPRING20\"}\n\nprint(validate_coupon(\"SUMMER10\", valid, expired))\nprint(validate_coupon(\"SPRING20\", valid, expired))\nprint(validate_coupon(\"UNKNOWN\", valid, expired))\nprint(validate_coupon(\"\", valid, expired))\n```\n\n\nFour explicit return points. Each one reads as a clear answer to a specific question. No accumulating state, no flag variable. You can scan the function top-to-bottom and trace each path.\n\n**Single return** keeps one exit at the bottom, often with a result variable that gets updated along the way:\n\n\n```python\ndef validate_coupon(code, valid_codes, expired_codes):\n result = False\n if code is None or code == \"\":\n result = False\n elif code in expired_codes:\n result = False\n elif code in valid_codes:\n result = True\n return result\n```\n\n\nOne `return` at the end. Every path goes through it. If you ever needed to add logging or modify the result before returning, you'd have exactly one place to do that.\n\n\n| Style | Strength | Weakness |\n| --- | --- | --- |\n| Multiple returns | Less nesting, edge cases handled and forgotten, easy to read top-down | Harder to inject \"always-do-this-before-returning\" logic; more total return statements to maintain |\n| Single return | One exit point makes pre-return work straightforward; one canonical answer | More indentation, more `elif` chains, more state to track mentally |\n\n\nPython culture leans toward multiple returns with guard clauses for clarity, especially in small functions. The single-return style shows up more often in long functions that build a result over several steps. The honest answer is \"use whichever makes this particular function easier to read\", and don't enforce one style globally.\n\nOne concrete case where single return wins: when there's cleanup or formatting work that should happen on every path. If a function has to print a log line, write to a file, or run any other \"always do this before exiting\" step, a single return at the bottom lets you place that step once. Returning early would either skip the step or force you to duplicate it at every exit.\n\n---\n\n# Returning Rich Types\n\nThe return value doesn't have to be a number or a string. Functions can hand back lists, dictionaries, custom objects, sets, tuples, or anything else that's a Python value.\n\n**Returning a list** is common when the function's job is \"give me everything that matches\".\n\n\n```python\ndef find_in_stock(catalog):\n in_stock = []\n for product in catalog:\n if product[\"stock\"] > 0:\n in_stock.append(product[\"name\"])\n return in_stock\n\ncatalog = [\n {\"name\": \"Wireless Mouse\", \"stock\": 12},\n {\"name\": \"USB Cable\", \"stock\": 0},\n {\"name\": \"HDMI Cable\", \"stock\": 3},\n {\"name\": \"Monitor Stand\", \"stock\": 0},\n]\n\navailable = find_in_stock(catalog)\nprint(available)\nprint(type(available))\n```\n\n\nThe function builds a fresh list, fills it in, and returns it. The caller owns that list; whatever the caller does with it doesn't affect anything inside the function. This is a clean shape because the result and the input don't share any mutable state.\n\n**Returning a dictionary** is the right call when the result has multiple named fields and you want them keyed by name, not by tuple position.\n\n\n```python\ndef compute_order_summary(cart, tax_rate):\n subtotal = sum(item[\"price\"] * item[\"quantity\"] for item in cart)\n tax = subtotal * tax_rate\n total = subtotal + tax\n return {\n \"subtotal\": round(subtotal, 2),\n \"tax\": round(tax, 2),\n \"total\": round(total, 2),\n \"item_count\": sum(item[\"quantity\"] for item in cart),\n }\n\ncart = [\n {\"name\": \"Wireless Mouse\", \"price\": 29.99, \"quantity\": 2},\n {\"name\": \"USB Cable\", \"price\": 4.99, \"quantity\": 3},\n]\nsummary = compute_order_summary(cart, 0.08)\nprint(summary)\nprint(summary[\"total\"])\n```\n\n\nA dictionary scales better than a tuple when the function's result has several named pieces. Compare `summary[\"total\"]` to `result[2]`: the dictionary version tells you what you're reading. If a future version of the function adds another field, the existing callers keep working as long as they only read the keys they already cared about.\n\nA tuple return shines when the number of values is small and fixed (two or three), the order is obvious (like a `(value, found)` pair), and you want unpacking on the caller side. A dictionary shines when the count might grow, the fields are named, or you want to pass the result around without unpacking it.\n\n**Returning a custom object** is the next step up. You've already used objects: a `datetime` is one, a file handle is one, a list is one. A function can return any of them. When you write your own class, you'll return instances of it the same way you'd return a list or a dict.\n\nA common rule of thumb: pick the simplest return type that lets the caller do its job.\n\n- One value: return that value (number, string, list, object).\n- A small fixed group: tuple plus unpacking.\n- A larger or growing group with named pieces: dictionary.\n- A complex value with behavior (methods, state): a custom class instance.\n\n---\n\n# Return vs Print\n\nThe single most useful split to understand about return values is this: **printing is for humans, returning is for code**.\n\nA function that only prints can talk to a person reading the screen. A function that returns can talk to other functions. The two roles don't conflict, but mixing them up leads to functions that \"work\" when you run them by hand and break the moment you try to use them inside something larger.\n\nStart with two versions of the same idea:\n\n\n```python\ndef print_total(cart):\n total = sum(cart)\n print(f\"Total: ${total:.2f}\")\n\ndef compute_total(cart):\n return sum(cart)\n```\n\n\nThe first version is fine if all you want is to see the number on the screen. The second version is fine for the same thing (`print(compute_total(cart))`) **and** lets you do more with the result.\n\n\n```python\ndef compute_total(cart):\n return sum(cart)\n\ncart = [29.99, 14.99, 9.99]\ntotal = compute_total(cart)\n\n# Composable: use the result anywhere.\nprint(f\"Total: ${total:.2f}\")\nprint(f\"After 10% off: ${total * 0.9:.2f}\")\nprint(f\"In cents: {int(total * 100)}\")\n```\n\n\nThe `print_total` version couldn't do any of those follow-ups. Once it printed, the number was gone. The `compute_total` version hands the number back, and the caller decides what to do with it. That's composability: each function does one job and produces a value the next function can build on.\n\nThe same split matters for testing. A function that returns is straightforward to test with a plain equality check (`assert compute_total([10, 20, 30]) == 60`). A function that only prints is harder to test, because the value lives inside `stdout` instead of in a variable you can compare against.\n\nA useful guideline: a function should generally **return or print, not both** for its primary output. Debug `print` calls during development are fine, but the actual answer should leave the function through `return`. The caller can wrap the call in `print` if they want it on the screen.\n\nThere are exceptions. A function whose job is the display itself (a renderer, a logger, a \"format this thing nicely\") is doing its real work through printing. Even then, splitting \"compute the formatted string\" from \"print the formatted string\" is often cleaner:\n\n\n```python\ndef format_total(cart):\n total = sum(cart)\n return f\"Total: ${total:.2f}\"\n\ndef print_total(cart):\n print(format_total(cart))\n\nprint_total([29.99, 14.99, 9.99])\nformatted = format_total([29.99, 14.99, 9.99])\nprint(formatted.upper())\n```\n\n\n`format_total` returns a string; `print_total` is a thin wrapper that prints it. Now you can use the formatted version for printing, logging, sending in an email, or stuffing into a larger string, without rewriting the formatting logic.\n\n---\n\n# Returning `None` Deliberately\n\n`None` isn't always a mistake. There are real reasons to return it on purpose: as a sentinel for \"no result\", as the marker that a function did its work through side effects, or as the explicit \"not found\" value.\n\nThe lookup-with-no-match shape is the most common:\n\n\n```python\ndef find_product(catalog, name):\n for product in catalog:\n if product[\"name\"] == name:\n return product\n return None\n\ncatalog = [\n {\"name\": \"Wireless Mouse\", \"price\": 29.99},\n {\"name\": \"USB Cable\", \"price\": 4.99},\n]\n\nresult = find_product(catalog, \"Webcam\")\nprint(result)\n\nif result is None:\n print(\"Not in catalog.\")\n```\n\n\nThe function either returns the matching product or `None`. The caller checks with `is None`, not `== None`, because `None` is a singleton and identity is the right comparison. The `(product, found)` tuple style we saw earlier is one alternative; returning `None` is the simpler version when there's no separate \"found\" flag to track.\n\nA function that exists for its side effects often returns `None` on purpose, just to be explicit:\n\n\n```python\ndef cancel_order(order_id, orders):\n if order_id not in orders:\n return None\n orders[order_id][\"status\"] = \"cancelled\"\n return None\n\norders = {\"ORD-1001\": {\"status\": \"placed\"}}\nprint(cancel_order(\"ORD-1001\", orders))\nprint(orders)\n```\n\n\nYou could also leave off the `return None` and rely on implicit `None`. Both are valid. Some teams prefer the explicit form because it documents \"I'm choosing to return nothing\", and some prefer the implicit form because it's shorter. Pick a style and stick to it; the code's behavior is identical either way.\n\nThe danger with `None` is when callers forget to check for it.\n\n\n```python\ndef find_product(catalog, name):\n for product in catalog:\n if product[\"name\"] == name:\n return product\n return None\n\ncatalog = [{\"name\": \"Wireless Mouse\", \"price\": 29.99}]\nresult = find_product(catalog, \"Webcam\")\nprint(result[\"price\"])\n```\n\n\n`result` is `None`, and you can't index into `None`. The fix is to check first:\n\n\n```python\ndef find_product(catalog, name):\n for product in catalog:\n if product[\"name\"] == name:\n return product\n return None\n\ncatalog = [{\"name\": \"Wireless Mouse\", \"price\": 29.99}]\nresult = find_product(catalog, \"Webcam\")\nif result is None:\n print(\"Not found.\")\nelse:\n print(result[\"price\"])\n```\n\n\nWhen you return `None` for \"no result\", document it. The caller has to know that `None` is a possible answer, otherwise they'll skip the check and run into the error above the first time the data doesn't have what they expected.\n\nIf `None` is a value the caller might also use as real data (a config value where `None` legitimately means \"unset\", for example), the `(value, found)` tuple shape is clearer than overloading `None`. A function that returns `(value, True)` for a key whose stored value is `None`, and `(None, False)` for a missing key, lets the caller tell the two cases apart. A plain `None` return collapses them into one indistinguishable answer.","pageType":"python"}

return Statement

Get Premium