When looking Python decorators someone made the statement, that they are as powerful as Lisp macros (particularly Clojure).
Looking at the examples given in PEP 318 it looks to me as if they are just a fancy way of using plain old higher-order functions in Lisp:
def attrs(**kwds):
def decorate(f):
for k in kwds:
setattr(f, k, kwds[k])
return f
return decorate
@attrs(versionadded="2.2",
author="Guido van Rossum")
def mymethod(f):
...
I haven’t seen any code transforming in any of the examples, like described in Anatomy of a Clojure Macro. Plus, Python’s missing homoiconicity could make code transformations impossible.
So, how do these two compare and can you say they are about equal in what you can do? Evidence seems to point against it.
Edit: Based on a comment, I’m looking for two things: comparison on “as powerful as” and on “as easy to do awesome things with”.
5
A decorator is basically just a function.
Example in Common Lisp:
(defun attributes (keywords function)
(loop for (key value) in keywords
do (setf (get function key) value))
function)
In above the function is a symbol (which would be returned by DEFUN) and we put the attributes on the symbol’s property list.
Now we can write it around a function definition:
(attributes
'((version-added "2.2")
(author "Rainer Joswig"))
(defun foo (a b)
(+ a b))
)
If we want to add a fancy syntax like in Python, we write a reader macro. A reader macro allows us to program on the level of s-expression syntax:
(set-macro-character
#@
(lambda (stream char)
(let ((decorator (read stream))
(arg (read stream))
(form (read stream)))
`(,decorator ,arg ,form))))
We then can write:
@attributes'((version-added "2.2")
(author "Rainer Joswig"))
(defun foo (a b)
(+ a b))
The Lisp reader reads above to:
(ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(DEFUN FOO (A B) (+ A B)))
Now we have a form of decorators in Common Lisp.
Combining macros and reader macros.
Actually I would do above translation in real code using a macro, not a function.
(defmacro defdecorator (decorator arg form)
`(progn
,form
(,decorator ,arg ',(second form))))
(set-macro-character
#@
(lambda (stream char)
(declare (ignore char))
(let* ((decorator (read stream))
(arg (read stream))
(form (read stream)))
`(defdecorator ,decorator ,arg ,form))))
The use is as above with the same reader macro. The advantage is that the Lisp compiler still sees it as a so-called top-level form – the *file compiler treats top-level forms specially, for example it adds information about them into the compile-time environment. In the example above we can see that the macro looks into the source code and extracts the name.
The Lisp reader reads the above example into:
(DEFDECORATOR ATTRIBUTES
(QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(DEFUN FOO (A B) (+ A B)))
Which then gets macro expanded into:
(PROGN (DEFUN FOO (A B) (+ A B))
(ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
(AUTHOR "Rainer Joswig")))
(QUOTE FOO)))
Macros are very different from reader macros.
Macros get the source code passed, can do whatever they want and then return source code. The input source does not need to be valid Lisp code. It can be anything and it could be written totally different. The result has to be valid Lisp code then. But if the generated code is using a macro too, then the syntax of the code embedded in the macro call could again be a different syntax. A simple example: one could write a math macro which would accept some kind of mathematical syntax:
(math y = 3 x ^ 2 - 4 x + 3)
The expression y = 3 x ^ 2 - 4 x + 3 is not valid Lisp code, but the macro could for example parse it and return valid Lisp code like this:
(setq y (+ (* 3 (expt x 2))
(- (* 4 x))
3))
There are many other use cases of macros in Lisp.
In Python (the language) the decorators cannot modify the function, only wrap it, so they are definitely far less powerful than lisp macros.
In CPython (the interpreter) the decorators can modify the function because they have access to the bytecode, but the function is compiled first and than can be fiddled with by the decorator, so it’s not possible to alter the syntax, a thing lisp-macro-equivalent would need to do.
Note, that modern lisps don’t use S-expressions as bytecode, so macros working on S-expression lists definitely work before bytecode compilation as as noted above, in python the decorator runs after it.
2
It is quite hard to use Python decorators to introduce new control flow mechanisms.
It is bordering-on-trivial to use Common Lisp macros to introduce new control flow mechanisms.
From this, it probably follows that they’re not equally expressive (I choose to interpret “powerful” as “expressive”, since I think that what they actually mean).
2
A decorator (be it in Python or in any other – functional programming – language) is just a function which accepts an original (to-be-decorated) function (and sometimes more additional arguments), and defines a new function while it calls the accepted function in its body but adds before or after the call some additional procedures to do. And at the end it returns this newly defined function.
So a function-returning-function-accepting function.
So a decorator is first of all a function (lambda) – and not a macro.
Python functions cannot do more than lisp lambdas. They are identical.
A decorator can serve as an abstraction for certain aspects/behaviors which a group of functions share.
And in that it is very powerful. You could say they are meta-functions – thus, meta-lambdas.
A decorator follows the open-closed principle – or helps to implement it for functions.
It can only add new behavior to existing functions.
It can not modify the original function call per se.
It can only add additional procedures to it – be it before or after calling the original function.
You can define decorator functions in Lisp, too, since it has lambdas.
These would be as-powerful-as – since they would be the exact identities.
How, I wrote here https://stackoverflow.com/a/77415072/9690090 .
So a decorator is a pure lambda construct.
Lisp macros, however, transform lisp code.
Lisp macros can take their arguments literally – and you have in lisp macros full control over the evaluation order of the arguments of the macro.
But most of all, Lisp macros are an abstraction over code.
Which is a different thing than an abstraction over function behavior/aspects using the rest of the language.
Lisp macros treat code as data and manipulate the course of the program at code-level.
So no, they are not equal in power.
Lisp macros can do stuff which lambdas can’t do.
You can add new control flow with lisp macros.
“as powerful as” – no.
and to “as easy to do awesome things with” I would say:
It is pointless to compare apples with bananas – they are different entities.
All what a decorator can do is a subset of all what a macro can do.
It’s certainly related functionallity, but from a Python decorator it’s not trivial to modify the method being called (that would be the f parameter in your example). To modify it you could go crazy with the ast module), but you’d be in for some pretty complicated programming.
Things along this line have been done though: check out the macropy package for some really mind-bending examples.
4