Why not tho? Decorators are very explicit markers of higher functions. When I see one, I know what's for.

It's rare that all users of a function will want it to be "production" or "parallel" or the rest in the piece.

Applying these functions as decorators, i.e. with @, means you can't run the non parallel version, or the test not in production, etc.

In the end, decorators, though nice on the first day of usage, reduce composability by restricting usage to whatever you wanted on that same day.

(this is not a general remark, it doesn't apply to DSLs that use decorators, e.g. flask)

To the extent that this is a real issue, you could just use a decorator that exposed the wrapped function as an attribute of the returned function object.

You could even write a higher order function, callable as a decorator, that would transform a decorator that didn't do this into one that was otherwise identical that did.

You’re saying write it this way instead?

    def my_func:
        ...

    my_decorated_func = my_decorator(my_func)

No they don't.

The decorator pattern is a well known one, where one "decorates" a function by passing it into another function. GP expresses that they would avoid the pattern with these decorators.

The decorator operator is essentially prefix notation of the form `f1 = f2(f1) = @ f2 f1` which is what the GP alluded to, i.e. that f2 is a higher order function since it takes a function and produces another function. In-fact, the @ operator is a higher order function as well since it takes 2 higher order functions.