Functions

Definition versus call

A function has two separate moments in a program's life. The first is the definition: the place where you give the function a name, list the inputs it expects, and write the statements that make up its body. In Python the keyword def introduces a definition; other languages use their own syntax, but the idea carries across languages. Defining a function does not run its body — it only records the recipe under a name for later use.

The second moment is the call: the point where you actually run the function by writing its name followed by parentheses, optionally passing in values. Each call executes the body from the top, using the values you supplied, and then returns control to wherever the call was made. A single definition can be called any number of times, from many places, with different inputs each time. Keeping these two moments distinct is the key mental model: the definition is written once, while calls can happen again and again. A common beginner error is to expect the body to run at the moment of definition rather than at the moment of a call.

Parameters, arguments, and return values

The names listed in a function's definition are its parameters — placeholders that stand for whatever values a caller will supply. The concrete values passed in at a specific call are its arguments. Python's own glossary keeps these terms apart: a parameter is a named entity in the definition, and an argument is a value passed when the function is called. When a call happens, each argument is bound to the matching parameter, and inside the body the parameter behaves like a local name holding that value.

A function usually reports a result with a return statement, which ends the call and hands a value back to the caller. That returned value can be stored in a variable, printed, or passed straight into another call. If a function finishes without reaching a return statement — or reaches a bare return — it still hands back a value: in Python that value is None, the language's way of saying 'nothing useful.' Functions that hand back a real result are sometimes called fruitful; those that act but return None are sometimes called void. How arguments actually bind to parameters, and which names are visible inside the body, is the subject of a separate topic, scope.

Why functions matter: reuse, abstraction, decomposition, testability

Functions earn their place for four connected reasons. Reuse: once logic lives in a function, you call it wherever you need it instead of copying code, which is the heart of the DRY principle — 'don't repeat yourself.' When the logic must change, you edit one definition rather than hunting down every copy. Abstraction: a good function name lets you use a piece of behavior without re-reading how it works, so you can think about what it does and ignore the details for now. Decomposition: breaking a large problem into smaller, well-named functions — a topic of its own — turns one overwhelming task into a set of manageable pieces you can build and understand one at a time. Testability: a function with clear inputs and a clear return value can be checked on its own, by calling it with known inputs and comparing the result to what you expect. These benefits compound. Libraries are collections of functions someone else wrote and tested; methods in object-oriented programming are functions attached to objects; and recursion is simply a function that calls itself. All of them build on the same habit of packaging work behind a name with defined inputs and outputs.

Pure functions and side effects

A function's return value is not always its only effect. A side effect is any change a function makes to the world outside its own local work — modifying a global variable, printing to the screen, writing a file, or changing a value that was passed in. A pure function has no side effects and depends only on its inputs: given the same arguments, it always returns the same result. An area function that just returns width times height is pure — it will return 15 for the inputs 5 and 3 every single time. A function that adds its argument to a shared running total is not pure: calling it twice with the same argument returns different results, because it both reads and changes outside state. Both kinds are useful — real programs need to print, save, and update data — but pure functions are the easiest to reuse, reason about, and test, so it helps to know which kind you are writing. This distinction was confirmed by running both versions in Python.