I'm not sure who this article is for, but I think it doesn't strike at the heart of the topic.

Half of the article is devoted to closures, but closures aren't essential for decorators. And the __closure__ attribute is an implementation detail that is really irrelevant. (For comparison, JavaScript has closures just like Python, but it doesn't expose the closed-over variables explicitly the way Python does.)

Decorators are simply higher order functions that are used to wrap functions. The syntax is a little funky, but all you need to know is that code like:

   @foo
   @bar
   def baz(args):
       return quux(args)

   baz = foo(bar(lambda args: quux(args))

Then there are seemingly more complex expressions like:

    @foo(42, 'blub')
    def bar(..): ...

    def foo(i, s):
        def decorator(f):
            def invoke(*args, **kwargs):
                print('decorator', i, s)
                f(*args, **kwargs)
                print('done')
        return invoke
    return decorator

    @foo(42, 'blub')
    def hello():
        print('Hello, world!')

    hello()

    # prints:
    #    decorator 42 blub
    #    Hello, world!
    #    done

And yes, these examples use closures, which are very convenient when implementing decorators. But they aren't essential. It's perfectly possible to declare a decorator this way:

    class Invoker:
        def __init__(self, f):
            self.f = f
    
        def __call__(self):
            print('before call')
            self.f()
            print('after call')
    
    def decorator(f):
        return Invoker(f)
        
    @decorator
    def hello():
        print('Hello, world!')

    hello()
    # prints:
    #     before call
    #     Hello, world!
    #     after call

The key point in all these examples is that functions in Python are first-class objects that can be referenced by value, invoked dynamically, passed as arguments to functions, and returned from functions. Once you understand that, it's pretty clear that a decorator is simply a wrapper that takes a function argument and returns a new function to replace it, usually adding some behavior around the original function.

One tiny correction:

> decorators are functions that take a callable argument and return a new callable

there's nothing forcing a decorator to return a callable. A decorator _could_ return anything it wants. I don't know why you would want that, but Python won't stop you.

The reference I usually offer people is https://stackoverflow.com/questions/739654/ . Admittedly the encyclopedic length answer there, while historically highly praised, barely addresses the actual question. But there's no real way to ask a suitable question for that answer - it's just way too broadly scoped. It's just one of those artifacts of the old days of Stack Overflow. Just, you know, good luck finding it if you don't already know about it.

I'm getting old. Something so obvious that I thought everybody knew is getting reiterated in a blogpost by a younger generation encountering it for the first time.

the thing that bothered me most reading through it was using decorators to mutate some global state with the `data` list variable.

like… it… just… it felt wrong reading that in the examples. felt very `def func(kw=[])` adjacent. i can see some rare uses for it, but eh. i dunno.

(also didn’t find the closure stuff that insightful, ended up skipping past that, but then i know decorators, so… maybe useful for someone else. i dunno.).