Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
11  
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 Oct 9 '13 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 Oct 9 '13 at 8:36
    
Maybe I should change the question to “as easy to do awesome things with” then. ;) –  Profpatsch Oct 9 '13 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 Oct 9 '13 at 8:43

4 Answers 4

up vote 11 down vote accepted

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:

(set-macro-character
 #\@
 (lambda (stream char)
   (let ((decorator (read stream))
         (arg (read stream))
         (form (read stream)))
     `(,decorator ,arg ,form))))

Now we can write:

@attributes'((version-added "2.2")
             (author "Rainer Joswig"))
(defun foo (a b)
  (+ a b))

Now we have a form of decorators in Common Lisp.

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. In the example above we can see that the macro looks into the source code and extracts the name.

Macros are totally different. They 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.

share|improve this answer

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.

share|improve this answer
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. –  delnan Oct 9 '13 at 15:08
2  
@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 Oct 9 '13 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).

share|improve this answer
    
I dare say s/quite hard/impossible/ –  delnan Oct 9 '13 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 Oct 10 '13 at 9:52

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.

share|improve this answer
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 Oct 9 '13 at 8:41
    
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 Oct 9 '13 at 11:54
    
@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 Oct 9 '13 at 11:55
1  
@JanHudec, in Lisp source language can have any (I really mean, any) syntax - see reader macros. –  SK-logic Oct 10 '13 at 8:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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