In lesson 04-01 a detail turned up that we parked for later: writing pause without parentheses raises no error. Python answers with something like <function pause at 0x7f3c9a1b2e50>, and type(pause) returns <class 'function'>. Back then we treated it as a trap to avoid; now we are going to turn it around and make it a tool.

Because that detail means something important: in Python, a function is a value like any other. If it is a value, it can be stored in a variable, printed, passed as an argument to another function and returned from a function. And that opens up a different way of writing code: instead of deciding inside a function exactly what it will do, the behaviour is passed in from outside.

It is the module's last piece, and the one that lets us finish EasyTask off: the three functions ask_text, ask_option and ask_integer share the same skeleton — ask, check, insist — and differ only in which check they perform. If the check can be an argument, the three become one.

1. A function without parentheses is a value
2. Higher-order functions
3. Anonymous functions with lambda
4. lambda or def: when to use each
5. Returning a function: factories
6. The callback pattern in EasyTask
7. Higher order over collections: a preview
8. Common mistakes and tips
9. Exercises
10. Conclusion of the module

Let us start by checking it in the REPL, with no tricks.

The first two lines treat greet as data: they print it and check its type, just as you would with a number. The third treats it as an action: the parentheses are the call operator.

If it is a value, it can be assigned to another variable:

Look carefully at what has happened: the function has not been copied; instead there are now two names pointing at the same function object, exactly as you saw with references in 04-03. The is confirms it. From that moment on, paint() and show_header() are exactly the same call.

This holds for built-in functions and for methods too: str.upper, len or input without parentheses are values you can store and pass around. It is the basis of everything that follows.

A higher-order function is one that receives another function as a parameter or returns a function. It sounds abstract; an example clears it up in three lines.

Inside apply_format, the parameter transformation is a local name pointing at whichever function was passed in; writing transformation(text) calls whatever has arrived. The function neither knows nor cares which one it is: the behaviour comes from outside.

And it works just the same with your own functions:

Note the decisive detail: in apply_format(text, mark_urgent), mark_urgent goes without parentheses. We are passing the function, not its result. If you wrote mark_urgent(...) you would be calling it right there and passing the string it returns, which is something completely different — and the number one source of errors in this lesson.

The advantage of this pattern is that it separates what repeats from what changes. apply_format is a skeleton; the specific transformation is a slot filled in on each call. You will see that this is exactly the problem with our three ask_* functions.

Sometimes the function you want to pass is so small that giving it a name and three lines of def is out of proportion. That is what lambda is for: an expression that creates a function with no name.

The three parts: the word lambda, the parameters separated by commas (no parentheses) and, after the colon, a single expression whose value is returned automatically. You do not write return: it is implicit.

That lambda is equivalent, point for point, to def double(n): return n * 2. Its type is the same, function, and it is called in the same way. Where it really shines is inside another call, with no name given:

Three different behaviours without writing three defs. The limitation, which is a strong one, you have already seen: a lambda can only contain one expression. No if/elif over several lines, no loops, no assignments, no multiple statements. The ternary operator of 03-01 does fit, because it is an expression:

And a point of style worth taking on board right now: double = lambda n: n * 2 is correct but discouraged. If you are going to give the function a name, use def: it gives you a docstring, a name visible in error messages and room to grow. The lambda is meant for nameless functions, used on the spot.

The practical decision rule fits into three questions. Are you going to use it more than once? Then def. Does it need more than one line, or does it deserve an explanation? Then def. Is it a trivial condition or transformation that reads better inside the call than as a separate definition three screens further up? Then lambda.

That last case is real and not rare: when the criterion is obvious, writing it in the same place where it is used saves the reader a trip to another part of the file. But as soon as the lambda starts having nested parentheses or a ternary inside another one, it has stopped clarifying and it is time to promote it to a def.

The other half of higher order is returning a function. A function that manufactures functions is informally called a factory, and it relies on the nested functions and the enclosing scope you saw in 04-03.

Analyse what happens, because it is subtler than it looks. create_greeting("Alba Studio") runs, defines the inner function greet and returns it; at that moment create_greeting finishes, and according to what you learnt in 04-03 its local variable studio_name ought to disappear. But it does not: the returned function carries with it the value it had. That is why greet_alba and greet_sole are two different functions, each with its own studio inside.

That mechanism has a name — a closure — and you do not need to master it today. It is enough to keep hold of the idea: a factory lets you create specialised versions of a function from a few configuration parameters, instead of repeating those parameters in every call.

Two complete validators from a single definition. Hold on to this idea: we are going to use it right now.

Look at the three functions from 04-02 with the flesh taken off:

The three have the same skeleton and differ only in the check. You already know what to do: turn that check into a parameter. A function passed in so that another one can call it is called a callback, because whoever receives it calls it back when it is needed.

Eight lines that replace the three previous functions. The contract is explicit: validator must be a function that receives a text and returns True or False. And now the validators, some with def and some with lambda, according to what the table in section 4 advises:

Four observations about this code:

• The first three validations are trivial and go in a lambda, written right where they are used: you can see at a glance what counts as valid for each field. The one for days has two chained checks and deserves a def with a name and a docstring.
• is_valid_days goes without parentheses. We are passing the function, not calling it. It is the mistake made most often here.
• The warning is a parameter with a default value (04-02), so each field can explain its own criterion without being forced to do so every time.
• ask_value always returns text, and the conversion to an integer is done outside, at the call. It is consistent with 04-04: the input function validates, and whoever uses it decides which type they want.

Has the program improved? It depends what you value. The honest table:

There is no absolute winner, and it is worth saying so plainly: higher order is a tool, not an automatic improvement. For a small program with three data types, the three specific functions read better. When validation criteria multiply and change often, ask_value wins hands down. What matters is that you can now choose, and that you recognise the pattern when you see it in other people's code, where it is common.

The place where higher order is used daily is over collections of data: sorting a list of tasks by priority, keeping only Nuria's, transforming them all in one go. The classic tools are sorted with its key parameter, and map and filter.

As you do not know lists yet, let us look at it with what you do have: a string, which is a sequence of characters. (sorted returns a list of characters, so we join them back together with "".join(...) in order to print them as text; lists arrive in module 5.)

Notice key=str.lower: it is a keyword argument whose value is a function. sorted calls it once per character and sorts by whatever it returns, not by the original character. That is why the third line ignores upper and lower case whereas the second puts the N at the front — capitals come first in character order. And max(..., key=len) picks the longest string instead of the alphabetically greatest one: the same old max, with a different criterion injected from outside.

That is the whole pattern. sorted does not know how to sort tasks by priority, but it does know how to sort anything at all if you tell it with a function what to look at in each element. When you reach Lists and arrays you will have real collections to apply it to, and in Sorting algorithms you will see how sorting works on the inside. map and filter, which apply a function to every element or select those that satisfy it, are also studied alongside collections; for now it is enough that you recognise the shape when you come across it.

Passing the call instead of the function. apply_format(text, mark_urgent()) runs mark_urgent right there — and with no arguments, so it gives a TypeError — and passes its result. To pass the function, write it without parentheses.

Forgetting the parentheses inside the higher-order function. The mirror-image error: if inside you write return transformation instead of transformation(text), you return the function object. Symptom: <function … at 0x…> is printed where you expected a text.

Cramming too much into a lambda. If you need a multi-branch if, a loop or an assignment, it does not fit: SyntaxError. Use def.

Giving a lambda a name. double = lambda n: n * 2 works, but you lose the docstring and a useful name in errors. If it has a name, make it a def.

Confusing the parameter with the function that arrives. Inside ask_value, validator is a local name: it may receive a lambda today and a def tomorrow. The function only requires it to be callable with a text and to return a boolean.

Tip: document the callback's contract. In the docstring, say what the function they pass you must receive and what it must return. Without that, whoever uses your function will have to read the body.

Tip: do not use higher order because it looks sophisticated. If two ifs solve the problem more clearly, then two ifs. Abstraction is paid for in reading effort, and it only pays off when it saves real repetition.

Say what each line prints and, where applicable, what error is produced and why.

Write create_labeller(prefix, width), a function that returns another function. The returned function receives a text and returns the prefix left-aligned in 10 characters followed by the text right-aligned in width characters, using the f-string formatting of 02-03. Use it to create two labellers — one for urgent tasks with the prefix [URGENT] and width 30, and another for notes with the prefix [note] and width 24 — and try them out with "Book fair poster".

Using ask_value(message, validator, warning) from section 6, write the call expressions needed to ask for these three values, deciding in each case whether the validator should be a lambda or a def and justifying it:

1. A client code: exactly four digits.
2. A yes-or-no answer: y or n, regardless of case.
3. A progress percentage: an integer between 0 and 100, and also a multiple of 5.

Solution 1.

f = frame creates a second name for the same object, so f("Sole Bakery") frames it just the same and frame is f is True. print(f) shows the representation of the function object. The first call to apply passes the function and works. The last one passes frame("Vidal"), which is evaluated before the call and holds "<<Vidal>>": inside apply, function is a string, and on trying function(value) Python protests with 'str' object is not callable. It is the same message you saw when shadowing a built-in in 04-03, and for the same reason: something that is not a function is being called.

Solution 2.

The inner function label reads prefix and width from the enclosing scope (the E of LEGB, 04-03) and carries on remembering them after create_labeller has finished. Compare this approach with passing prefix and width on every call: the factory saves you repeating them, and into the bargain makes it clear that an urgency labeller is one thing and a note labeller is another.

Solution 3.

The first two criteria fit comfortably into one expression and read better inside the call, so lambda it is. The third needs to convert the text into a number after checking that it can be converted, and that is two steps with an intermediate variable: impossible in a readable lambda, and besides it deserves a docstring explaining the multiple-of-5 rule. That if not text.isdigit(): return False is, by the way, the guard clause of 04-02 doing its job: without it, int(text) would blow up with a ValueError at the sight of any letter.

Functions are data too. Without parentheses, a function name is a value of type function that can be printed, assigned to another variable and passed around; with parentheses, it is a call. From there come higher-order functions: those that receive a function as a parameter — you supply the skeleton, the caller supplies the specific behaviour — and those that return a function, the factories, capable of creating specialised versions that remember their configuration. For tiny throwaway functions there is lambda, limited to a single expression and with no explicit return; for everything else, def. And the callback pattern — passing the check as an argument — has unified EasyTask's three ask_* functions into a single ask_value.

That closes module 4. You know how to define and call functions, and to tell the definition from the call (04-01). You know how to give them positional, keyword and default-valued parameters, and how to make them return one or several values with return, understanding why returning nearly always beats printing (04-02). You know where each name lives thanks to the LEGB rule, why changing globals are a problem and why constants are not (04-03). You know how to break down a whole program with checkable criteria: one responsibility per function, uniform levels of abstraction, input and output kept apart from logic, DRY without over-fragmenting, and a main() protected by if __name__ == "__main__": (04-04). And you know that functions are values that get passed and returned (04-05).

easytask.py has reached version 0.7: constants at the top, functions grouped by families, a twenty-two-line main() that reads like a table of contents, zero duplication and eight pieces reusable in any other program. It is an enormous leap from the wall of v0.6.

And yet, it still manages one single task. Marta cannot have the book fair poster, the Solé Bakery menu and the Vidal account job all at once: registering one destroys the previous one. The six loose variables — title, assignee, priority, days, completed, has_task — travel together from function to function because they are, in truth, one single thing without a name. And show_card(title, assignee, priority, days, completed) with its five parameters is the most visible symptom.

Both things — storing many tasks and grouping the data of each one — are solved by the same means: data structures. That is module 5, which begins with Lists and arrays: the tool that will finally let EasyTask manage the real work of Alba Studio, walk through it with a for, search in it, sort it by priority and, when we get to files, still have it there tomorrow morning.