{"id":285,"date":"2026-04-19T20:55:16","date_gmt":"2026-04-19T20:55:16","guid":{"rendered":"http:\/\/askpython.com\/?p=285"},"modified":"2026-04-20T09:14:36","modified_gmt":"2026-04-20T09:14:36","slug":"python-functions","status":"publish","type":"post","link":"https:\/\/www.askpython.com\/python\/python-functions","title":{"rendered":"Python Functions"},"content":{"rendered":"\n

Functions are how you name behavior. Instead of writing the same five lines every time you need to validate user input, you write those five lines once, give them a name like validate_input<\/code>, and call that name whenever you need it. That act of naming is the core purpose of a function and the starting point for everything else in this guide.<\/p>\n\n\n\n

This is not a beginner glossary entry. If you have written Python for a few weeks and find yourself copying blocks of code between files or writing the same logic in multiple places, this is where that habit ends. We will cover what functions actually do well, where they trip people up, and the patterns that make a function easy to test, read, and reuse.<\/p>\n\n\n\n

Defining and Calling a Function<\/h2>\n\n\n\n

The syntax is straightforward. A function definition starts with def<\/code>, followed by the name, parentheses for parameters, and a colon. The body is indented.<\/p>\n\n\n

\n\ndef greet(name):\n    return f"Hello, {name}"\n\n<\/pre><\/div>\n\n\n
Calling the function is what actually runs the body:<\/p>\n\n\n
\n\nmessage = greet("Alice")\nprint(message)  # Hello, Alice\n\n<\/pre><\/div>\n\n\n
If you omit the return<\/code> statement, the function returns None<\/code> by default. This is a common source of confusion when you expect a modified object or a computed value but get nothing back.<\/p>\n\n\n\n
Parameters and Arguments<\/h2>\n\n\n\n
Parameters are the names in the function definition. Arguments are the values you pass when calling. Python separates these cleanly and gives you several ways to pass them.<\/p>\n\n\n\n
Positional arguments<\/strong> are the default. They map to parameters by position:<\/p>\n\n\n
\n\ndef power(base, exponent):\n    return base ** exponent\n\nresult = power(2, 3)  # base=2, exponent=3, result=8\n\n<\/pre><\/div>\n\n\n
Keyword arguments<\/strong> let you name the parameter explicitly at the call site, which makes the intent clear and allows you to reorder:<\/p>\n\n\n
\n\nresult = power(exponent=3, base=2)  # same result, unambiguous\n\n<\/pre><\/div>\n\n\n
Default parameter values<\/strong> let callers omit arguments that have sensible defaults:<\/p>\n\n\n
\n\ndef power(base, exponent=2):\n    return base ** exponent\n\nprint(power(4))    # 16, uses default exponent=2\nprint(power(4, 3)) # 64, overrides default\n\n<\/pre><\/div>\n\n\n
One rule that trips up newcomers: never use a mutable object like a list or dict as a default argument. Python evaluates defaults once at definition time, not at call time. If you mutate the default, that mutation persists across calls:<\/p>\n\n\n
\n\n# Wrong\ndef add_item(item, items=[]):\n    items.append(item)\n    return items\n\nprint(add_item("first"))   # ['first']\nprint(add_item("second"))  # ['first', 'second'] \u2014 bug!\n\n# Correct\ndef add_item(item, items=None):\n    if items is None:\n        items = []\n    items.append(item)\n    return items\n\nprint(add_item("first"))   # ['first']\nprint(add_item("second"))  # ['second']\n\n<\/pre><\/div>\n\n\n
Returning Values<\/h2>\n\n\n\n
A Python function can return any object. Returning multiple values is done by packing them into a tuple, which the caller can unpack:<\/p>\n\n\n
\n\ndef divide_with_remainder(a, b):\n    quotient = a \/\/ b\n    remainder = a % b\n    return quotient, remainder\n\nq, r = divide_with_remainder(17, 5)\nprint(q, r)  # 3 2\n\n<\/pre><\/div>\n\n\n
The return<\/code> statement ends the function immediately. Any code after a return<\/code> inside the function body never runs. This is useful for early exits:<\/p>\n\n\n
\n\ndef process(data):\n    if not data:\n        return None  # nothing to process\n    # expensive operations here\n    return transformed\n<\/pre>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2 class="wp-block-heading">Variable Scope: Local, Global, Nonlocal<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Variables defined inside a function are local to that function. They do not exist outside the function body, and they shadow any variables with the same name in the outer scope:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:syntaxhighlighter\/code {"language":"python"} -->\n<pre class="wp-block-syntaxhighlighter-code">\ndef scope_demo():\n    x = 10  # local variable\n    print(x)  # 10\n\nscope_demo()\nprint(x)  # NameError: x is not defined\n\n<\/pre><\/div>\n\n\n
To modify a global variable from inside a function, declare it with global<\/code>:<\/p>\n\n\n
\n\ncounter = 0\n\ndef increment():\n    global counter\n    counter += 1\n\nincrement()\nprint(counter)  # 1\n\n<\/pre><\/div>\n\n\n
Global state makes testing difficult. If a function reads or modifies global variables, you cannot test it in isolation. Passing values as parameters and returning results is almost always the better design.<\/p>\n\n\n\n
nonlocal<\/code> is used when you have a nested function and need to modify a variable from the enclosing scope:<\/p>\n\n\n
\n\ndef outer():\n    count = 0\n    def inner():\n        nonlocal count\n        count += 1\n        return count\n    return inner\n\ncounter_fn = outer()\nprint(counter_fn())  # 1\nprint(counter_fn())  # 2\n\n<\/pre><\/div>\n\n\n
*args and **kwargs: Flexible Parameters<\/h2>\n\n\n\n
The *args<\/code> syntax lets a function accept any number of positional arguments. The function receives them as a tuple:<\/p>\n\n\n
\n\ndef sum_all(*numbers):\n    total = 0\n    for n in numbers:\n        total += n\n    return total\n\nprint(sum_all(1, 2, 3))        # 6\nprint(sum_all(10, 20, 30, 40))  # 100\n\n<\/pre><\/div>\n\n\n
**kwargs<\/code> does the same for keyword arguments, packing them into a dictionary:<\/p>\n\n\n
\n\ndef print_config(**settings):\n    for key, value in settings.items():\n        print(f"{key} = {value}")\n\nprint_config(host="localhost", port=8080, debug=True)\n\n<\/pre><\/div>\n\n\n
You can combine all three in one function signature: positional, *args<\/code>, and **kwargs<\/code>. Python enforces the order: positional parameters first, then *args<\/code>, then keyword-only parameters, then **kwargs<\/code>.<\/p>\n\n\n\n
Functions as First-Class Objects<\/h2>\n\n\n\n
In Python, functions are objects. You can assign them to variables, pass them as arguments to other functions, return them from functions, and store them in data structures. This is not a special feature \u2014 it is built into the language design.<\/p>\n\n\n\n
Passing a function as an argument is the basis for callbacks, middleware, and strategy patterns:<\/p>\n\n\n
\n\ndef apply_twice(fn, value):\n    return fn(fn(value))\n\ndef add_three(x):\n    return x + 3\n\nprint(apply_twice(add_three, 0))  # 6: (0+3)+3\n<\/pre>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Returning a function from a function is how decorators and factories work:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:syntaxhighlighter\/code {"language":"python"} -->\n<pre class="wp-block-syntaxhighlighter-code">\ndef make_multiplier(factor):\n    def multiply(x):\n        return x * factor\n    return multiply\n\ndouble = make_multiplier(2)\ntriple = make_multiplier(3)\nprint(double(5))   # 10\nprint(triple(5))   # 15\n\n<\/pre><\/div>\n\n\n
make_multiplier<\/code> returns a function that closes over the factor<\/code> variable. That is a closure \u2014 which brings us to the next section.<\/p>\n\n\n\n
Closures and Why They Matter<\/h2>\n\n\n\n
A closure is a function that remembers values from the scope where it was defined, even after that scope has finished executing. The factor<\/code> in the multiply<\/code> function is captured from make_multiplier<\/code>‘s local scope and stays alive as long as multiply<\/code> exists.<\/p>\n\n\n\n
Closures show up constantly in real code. They are how you attach behavior to data without using a full class:<\/p>\n\n\n
\n\ndef make_counter():\n    count = 0\n    def counter():\n        nonlocal count\n        count += 1\n        return count\n    return counter\n\nclick_counter = make_counter()\nprint(click_counter())  # 1\nprint(click_counter())  # 2\nprint(click_counter())  # 3\n\n<\/pre><\/div>\n\n\n
The inner counter<\/code> function is a closure that holds onto count<\/code>. Each call to click_counter()<\/code> increments that captured value. You get stateful behavior without a class or any mutable global.<\/p>\n\n\n\n
Lambda Functions<\/h2>\n\n\n\n
A lambda is an anonymous single-expression function. It is useful when you need a small throwaway function and writing a full def<\/code> block feels like overkill:<\/p>\n\n\n
\n\nnumbers = [3, 1, 4, 1, 5, 9, 2, 6]\nsorted_by_mod_3 = sorted(numbers, key=lambda x: x % 3)\nprint(sorted_by_mod_3)  # [3, 9, 6, 1, 1, 4, 5, 2]\n\n<\/pre><\/div>\n\n\n
The same logic as a named function:<\/p>\n\n\n
\n\ndef mod_3(x):\n    return x % 3\n\nsorted_by_mod_3 = sorted(numbers, key=mod_3)\n\n<\/pre><\/div>\n\n\n
Use lambdas when the function is genuinely simple and used in one place. If the expression grows past a couple of lines or is used in multiple places, write a named function instead. A lambda can only contain an expression \u2014 not statements like assignment.<\/p>\n\n\n\n
Type Hints and Docstrings<\/h2>\n\n\n\n
Type hints make it clear what a function expects and what it returns. They do not enforce anything at runtime by default, but they make code review faster, IDE support better, and bugs easier to catch with tools like mypy:<\/p>\n\n\n
\n\ndef greet(name: str, times: int = 1) -> str:\n    return (f"Hello, {name}! " * times).strip()\n\nprint(greet("Alice"))       # Hello, Alice!\nprint(greet("Bob", 3))     # Hello, Bob! Hello, Bob! Hello, Bob!\n\n<\/pre><\/div>\n\n\n
Docstrings document what a function does. The minimal useful docstring covers the purpose, parameters, and return value:<\/p>\n\n\n
\n\ndef divide_with_remainder(a: int, b: int) -> tuple[int, int]:\n    """Return the quotient and remainder of a divided by b.\n\n    Args:\n        a: The dividend.\n        b: The divisor (must be non-zero).\n\n    Returns:\n        A tuple of (quotient, remainder).\n    """\n    if b == 0:\n        raise ValueError("divisor cannot be zero")\n    return a \/\/ b, a % b\n<\/pre>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>A docstring that just says "This function does something" is not useful. A docstring that tells you what it returns, what exceptions it raises, and what the parameters mean is something you will thank yourself for six months later.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2 class="wp-block-heading">Frequently Asked Questions<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:heading {"level":3} -->\n<h3 class="wp-block-heading">Should I use global variables inside functions?<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Almost never. Global state makes functions harder to test, harder to reason about, and a common source of subtle bugs when multiple parts of the code modify the same variable. Pass values as parameters and return results instead. If you find yourself using <code>global<\/code> in production code, it is a signal to reconsider the design.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {"level":3} -->\n<h3 class="wp-block-heading">What is the difference between *args and a list parameter?<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>A list parameter requires the caller to pack arguments into a list before calling. <code>*args<\/code> lets the caller pass any number of positional arguments naturally, and the function receives them as a tuple. Both work, but <code>*args<\/code> is more readable when the function genuinely accepts a variable number of values:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:syntaxhighlighter\/code {"language":"python"} -->\n<pre class="wp-block-syntaxhighlighter-code">\n# Less natural for the caller\ndef sum_all(numbers):\n    return sum(numbers)\n\nsum_all([1, 2, 3])\n\n# More natural\ndef sum_all(*numbers):\n    return sum(numbers)\n\nsum_all(1, 2, 3)\n\n<\/pre><\/div>\n\n\n
When should I use a lambda instead of a named function?<\/h3>\n\n\n\n
Use a lambda when you need a small function for one specific use and defining it as a named function would add noise. sorted(my_list, key=lambda x: x['score'])<\/code> is cleaner than defining a separate get_score<\/code> function just for that one sort. If the lambda logic is complex enough that it needs a comment, use a named function instead.<\/p>\n\n\n\n
Can a function return multiple values?<\/h3>\n\n\n\n
A function returns exactly one object. When you write return a, b<\/code>, Python packages those into a tuple under the hood. The caller can then unpack them into separate variables, which makes it look like multiple return values. This is a common pattern and entirely intentional in Python.<\/p>\n\n\n\n
How do closures differ from classes for maintaining state?<\/h3>\n\n\n\n
Classes and closures can both maintain state. Classes are more explicit and are the right tool when the state is complex or you need multiple methods. Closures are lighter weight and useful when you have a single piece of state or need a simple callable. Once a closure grows to the point where you are managing several captured variables, it is usually clearer to switch to a class.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
Functions are how you name behavior. Instead of writing the same five lines every time you need to validate user input, you write those five lines once, give them a name like validate_input, and call that name whenever you need it. That act of naming is the core purpose of a function and the starting […]<\/p>\n","protected":false},"author":3,"featured_media":66383,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-285","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-python"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/posts\/285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/comments?post=285"}],"version-history":[{"count":0,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/posts\/285\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/media\/66383"}],"wp:attachment":[{"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/media?parent=285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/categories?post=285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.askpython.com\/wp-json\/wp\/v2\/tags?post=285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}