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

       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”.

  • 12
    Of course decorators are not real macros. They cannot translate an arbitrary language (with a totally different syntax) into python. Those who claim the opposite simply do not understand the macros.
    – SK-logic
    Commented Oct 9, 2013 at 8:35
  • 1
    Python isn't homoiconic, however it is very very dynamic. Homoiconicity is only required for powerful code transformations if you want to do it at compile time--if you have support for direct access to the compiled AST and tools to alter it, you can do it at runtime regardless of language syntax. That being said, "as powerful as" and "as easy to do awesome things with" are very different concepts.
    – Phoshi
    Commented Oct 9, 2013 at 8:36
  • Maybe I should change the question to “as easy to do awesome things with” then. ;)
    – Profpatsch
    Commented Oct 9, 2013 at 8:40
  • Maybe someone can hack up some comparable Clojure higher-order function to the Python example above. I tried but criss-crossed my mind in the process. Since the Python example uses object attributes this has to be a bit different.
    – Profpatsch
    Commented Oct 9, 2013 at 8:43
  • @Phoshi Altering the compiled AST at run-time is known as: self-modifying code.
    – Kaz
    Commented Oct 7, 2017 at 1:12

5 Answers 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))

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:

  '((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:

 (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:

                    (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)
     (,decorator ,arg ',(second form))))

 (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:

           (AUTHOR "Rainer Joswig")))
  (DEFUN FOO (A B) (+ A B)))

Which then gets macro expanded into:

                           (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))

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.

  • 1
    You don't need to modify the function. You only need to read the code of the function in some form (in practice, this means bytecode). Not that this makes it any more practical.
    – user7043
    Commented Oct 9, 2013 at 15:08
  • 3
    @delnan: Technically, lisp is not modifying it either; it is using it as source to generate a new one and so would python, yes. The problem lies in the absence of token list or AST and the fact the compiler already complained about some things that you might otherwise allow in the macro.
    – Jan Hudec
    Commented Oct 9, 2013 at 15:37

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).

  • I dare say s/quite hard/impossible/
    – user7043
    Commented Oct 9, 2013 at 15:10
  • @delnan Well, I wouldn't go quite so far as to say "impossible", but you'd definitely have to work at it.
    – Vatine
    Commented Oct 10, 2013 at 9:52

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.

  • 3
    Even the ast-transforming stuff in python is not equal to the Lisp macros. With Python, the source language should be Python, with Lisp macros the source language transformed by a macro can be, literally, anything. Therefore, Python metaprogramming is only suitable for simple things (like AoP), while Lisp metaprogramming is useful for implementing powerful eDSL compilers.
    – SK-logic
    Commented Oct 9, 2013 at 8:41
  • 1
    The thing is that macropy is not implemented using decorators. It uses the decorator syntax (because it must use a valid python syntax), but it is implemented by hijacking the byte compilation process from an import hook.
    – Jan Hudec
    Commented Oct 9, 2013 at 11:54
  • 1
    @SK-logic: In Lisp the source language also has to be lisp. Just Lisp syntax is very simple but flexible, while python syntax is much more complex and not so flexible.
    – Jan Hudec
    Commented Oct 9, 2013 at 11:55
  • 2
    @JanHudec, in Lisp source language can have any (I really mean, any) syntax - see reader macros.
    – SK-logic
    Commented Oct 10, 2013 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.