Question 1

Decorator wrapper with *args

Accepted Answer

The decorator replaces `add` with `wrapper`. Calling `add(3, 4)` calls `wrapper(3, 4)`, which calls the original `add(3, 4)` - returning 7 - then multiplies by 2. Using `*args` and `**kwargs` in the wrapper is exactly why the decorator works for any function signature. Without those, passing two arguments would fail at the `wrapper` call.

Question 2

What does the @ syntax do?

Accepted Answer

The `@` syntax is pure shorthand - Python calls `my_decorator(func)` and rebinds the name `func` to whatever that returns. Once you see it as a simple reassignment, decorators stop feeling like magic and start feeling like a naming convenience. The other options either invent non-existent APIs or skip the call entirely.

Question 3

Function name after decoration

Accepted Answer

Without `functools.wraps`, the decorated function's `__name__` becomes the name of the inner wrapper, not the original function. The name `greet` now points to `wrapper`, so `greet.__name__` is `'wrapper'`. This is exactly why `@functools.wraps(func)` exists - it copies `__name__`, `__doc__`, and other metadata from the original function onto the wrapper.

Question 4

functools.wraps preserves metadata

Accepted Answer

Applying `@wraps(func)` to the inner wrapper copies the original function's `__name__`, `__doc__`, `__qualname__`, and other attributes onto `wrapper`. So even though `compute` now points to `wrapper`, `compute.__name__` reports `'compute'`. Without `@wraps`, you'd get `'wrapper'` instead - which breaks logging, introspection, and test frameworks that rely on function names.

Question 5

Decorator that takes arguments

Accepted Answer

A decorator that takes arguments needs an extra layer of nesting: `repeat(3)` returns `decorator`, and `decorator(say)` returns `wrapper`. The `@repeat(3)` line calls `repeat(3)` first, producing the actual decorator, which then wraps `say`. Calling `say('hi')` runs the loop 3 times, printing `'hi'` on each iteration.

Question 6

Stacked decorators apply bottom-up

Accepted Answer

Stacked decorators apply bottom-up: `@double` wraps `value` first, then `@add_one` wraps the result. Calling `value()` calls `add_one`'s wrapper, which calls `double`'s wrapper, which calls the original `value()` returning 3. Then `double` multiplies by 2 to get 6, and `add_one` adds 1 to get 7. If the order were reversed the result would be `(3 + 1) * 2 = 8` - so the stacking order matters whenever the decorators interact.

Question 7

Decorator capturing state via closure

Accepted Answer

The `calls` variable lives in the enclosing scope of `wrapper` - it is shared across all calls because there is only one closure created at decoration time. Each call to `ping()` increments the same `calls` counter and prints its current value. You need `nonlocal calls` to reassign a variable from an enclosing scope; without it, Python would treat `calls` as a local and raise an `UnboundLocalError`.

Question 8

What @property does

Accepted Answer

@property turns a method into a managed attribute. obj.area reads like a field but runs the getter method under the hood. You can pair it with @area.setter and @area.deleter to control writes and deletes too, giving you validation logic without forcing callers to use get_area() and set_area() style methods. This is how Python implements encapsulation cleanly - start with a plain attribute, and if you later need logic, add @property without changing the calling code.

Question 9

Decorator with arguments drops return value

Accepted Answer

The `wrapper` function calls `func` in a loop but never returns anything - so it implicitly returns `None`. The original `compute` does return a value, but that return value is discarded inside the loop. To preserve the return value you would need to capture and return the result of the last call: `result = func(*args, **kwargs)` then `return result` after the loop.

Question 10

Stacked decorators and __name__ without wraps

Accepted Answer

Without `@wraps`, each decorator's inner `wrapper` overwrites the function's `__name__`. After `@italic` wraps `title`, `__name__` is `'wrapper'`. After `@bold` wraps that, `__name__` is still `'wrapper'` (bold's wrapper). For the output, decorators apply bottom-up: `italic` wraps first producing `hello`, then `bold` wraps that producing `hello`.

Question 11

Class-based decorator mechanics

Accepted Answer

When Python sees `@MyClass`, it calls `MyClass(func)` at definition time, storing the result as the new function name. Calling the decorated function later triggers `instance.__call__(...)`, so the class must define `__call__` to make its instances behave like functions. `__init__` receives the original function when the class is instantiated, but `__call__` is what makes the resulting object invocable like a regular function.

Question 12

What functools.wraps does

Accepted Answer

When you wrap a function, the wrapper replaces it - so without functools.wraps, the decorated function's __name__ becomes 'wrapper' and its docstring disappears. That breaks tools like help(), logging, and debuggers that rely on the function's name. Adding @functools.wraps(func) to your inner wrapper copies __name__, __qualname__, __doc__, __annotations__, and __module__ over automatically. It is one line and you should always include it in any decorator you write.

Decorators