Configure Callbacks with functools.partial

Select a timestamp to watch that moment on YouTube.

1. 00:00

   A callback is a function you hand to another part of a program to call later. Often the callback needs a little configuration: a multiplier, a log level, or a destination. One tempting way to create several callbacks is a lambda inside a loop. But the lambda may look up the loop variable when it runs, after the loop has finished. Then every callback sees the final value. Python's `functools.partial` provides a direct way to bind some arguments now and supply the remaining arguments later. We will reproduce the loop bug, fix it with `partial`, and build a small event formatter that uses a preconfigured level.

2. 00:40

   No user-interface framework is required; a list of functions is enough to demonstrate deferred calls. Pay attention to when each value is chosen. The function passed to `partial` remains the original callable, and the new callable remembers selected arguments. This is a useful pattern for adapters and callbacks, but it should not hide complex state or validation. We will test the behavior with more than one input. The callbacks are created while `factor` takes the values two, three, and four. They are invoked only after the loop ends, when the variable refers to four. Each lambda then multiplies five by four, producing twenty three times.

3. 01:22

   The code did not store three separate factor values inside the lambdas. This behavior is called late binding of the captured name. A common fix is to use a default argument in the lambda, such as `lambda value, factor=factor: ...`, which captures the current value. That is valid, but it can be easy to miss in a larger expression. If the operation already exists as a named function, `partial` makes the configuration step explicit. We will bind each factor when building the list. The key test is to invoke the callbacks later, not inside the loop, because invoking them immediately can conceal this exact bug.

4. 02:03

   Different input values should still work once the factor is captured correctly. Each call to `partial` creates a new callable with its own bound `factor`. When we later supply `value=5`, the three functions return ten, fifteen, and twenty. The first callback still accepts another value, so seven becomes fourteen. This is partial application: provide some arguments now and the rest at call time. We bound `factor` by keyword because it says what the number means. A partial can also bind leading positional arguments, which is useful for a callback such as a warning logger where the level should always be `WARN`.

5. 02:43

   The original `scale` function has not changed; it still accepts both arguments. `partial` packages a function together with the choices we have made for one use. Do not assume a partial validates values. If a factor must be positive or a level must be from an allowed set, the underlying function or the creation step should enforce that rule. Next we will use this pattern to configure a readable event message. `warn` is a callable configured with the first argument of `format_event`. The caller supplies only the message. That makes it easy to pass to another function that expects a one-argument callback.

6. 03:23

   Two different messages show that the level is fixed while the message remains variable. The original `format_event` still accepts an `INFO` level because `partial` creates a wrapper; it does not mutate the function definition. The validation belongs in the underlying function, so every path through it checks the level. In an application, you might pass `warn` to a queue consumer, a parser, or a UI event handler. The receiver does not have to know about the level argument at all. Be careful with mutable bound arguments such as lists or dictionaries: a partial holds references to objects, so later mutation can affect calls.

7. 04:03

   Here the bound string is immutable and simple. The lesson page includes a task where you configure a callback and then invoke it with several inputs to show what is fixed and what remains open. Two separate partials keep their factors independent. The assertions use positive, zero, and negative inputs so the test does more than repeat one sample. The configured warning callback includes the fixed level and the supplied message. An unsupported level still raises an error through the general function. This shows `partial` did not bypass validation. Try replacing the two partials with lambdas built in a loop and invoking them

8. 04:44

   afterward; you should be able to predict the repeated factor from the broken run. Then try binding a factor positionally versus by keyword and inspect which arguments remain available. `partial` is useful when a function's behavior should be configured before it is passed somewhere else. It does not make hidden global state disappear by itself; the clarity comes from explicitly recording selected arguments at creation time and testing calls later. Complete the practice task by producing callbacks with distinct retained settings and explaining when each argument is chosen.