ansaurus

Question

Answer 1

A:

Some uses cases I have seen before include making class factories or stripping logging statements out of production code.

Rick Copeland 2009-04-18 23:00:39

Answer 2

+3 A:

There's a mailing list posting (archive.org mirror) which explains this rather well. The post is about Perl, but it applies to Python just as well.

lfaraone 2009-04-18 23:01:42

The link is broken

Casebash 2009-09-21 05:32:53

added a mirror.

lfaraone 2009-09-22 20:22:31

Answer 3

+4 A:

I believe that macros run counter to Python's culture. Macros in Lisp allow the big ball of mud approach; you get to redefine the language to become more suited to your problem domain. Conversely Pythonic code uses the most natural built in feature of Python to solve a problem, instead of solving it in a way that would be more natural in a different language.

Macros are inherently unpythonic.

RossFabricant 2009-04-18 23:05:46

That's kind of begging the question, though, isn't it? If macros were added to the language, by that logic, they'd become "pythonic", just as decorators, list comprehensions, the conditional expression, metaclasses, etc. would not have been considered "pythonic" before they were added as built-in features to the language. What makes macros less pythonic than, say, using sys._getframe() and metaclasses?

Rick Copeland 2009-04-18 23:12:51

You'd be right, but this is usually in reference to PEP 20 http://www.python.org/dev/peps/pep-0020/ and the like which outline the general philosophy of the language. In this case, I think macros are likely to go against several of the linked guidelines.

Dana the Sane 2009-04-18 23:23:32

I'm familiar with the Zen of Python; I'm just not convinced that macros are necessarily in opposition to it.

Rick Copeland 2009-04-18 23:49:09

I think it would depend how they're implemented. Looking at the metapython link provided in the question, I see a few problems.

Dana the Sane 2009-04-19 01:40:55

Pythonic style is like the style of a font. List comprehensions et al. are like different letters in the Python font. Macros are like meta rules to let you generate your own font.

RossFabricant 2009-04-20 02:00:33

Macros aren't necessary -- which makes them unpythonic. There aren't any sensible use cases. Examples from other languages don't apply here. Macros are a source-level workaround to language gaps.

S.Lott 2009-04-20 16:03:43

Macros are a point in a space of trade-offs in language design. They tradeoff performance vs dynamism (by limiting the neccesity to call eval at runtime, allowing compiler to apply logic for optimization, type-checking, type-inference). Macros are neccessary to be able to introduce useful abstractions while retaining ability to do useful optimizations. This is one of the reasons why Common Lisp implementations are fast and CPython is slow - one can not easily remove interpreter overhead.

dmitry_vk 2009-04-20 20:50:07

@dmitry I think the tradeoff is between powerful abstractions and code clarity. Performance seems to be unrelated.

RossFabricant 2009-04-20 22:09:46

rossfabricant: have a look at http://en.wikipedia.org/wiki/Fexpr . Fexprs allow same kind of code clarity and are more powerful than macros (in terms of computations that are possible with them; everything that is possible to do with macros is possible to do with fexprs; but not the other way).

dmitry_vk 2009-04-25 10:49:52

At the core, macros are about inventing new (better?) ways of saying the same thing. Doing the same thing only different sounds very un-pythonic, probably. Consult "import this".

Aaron 2009-04-29 01:16:04

Answer 4

+3 A:

In lisp, macros are just another way to abstract ideas.

This is an example from an incomplete ray-tracer written in clojure:

(defmacro per-pixel
  "Macro.
Excecutes body for every pixel. Binds i and j to the current pixel coord."
  [i j & body]
  `(dotimes [~i @width]
     (dotimes [~j @height]
       ~@body)))

If you want to do something to every pixel with coordinates (i,j), say, draw a black pixel if i is even, you would write:

(per-pixel i,j
  (if (even? i)
    (draw-black i,j)))

This is not possible to do without macros because @body can mean anything inside (per-pixel i j @body)

Something like this would be possible in python as well. You need to use decorators. You can't do everything you can do with lisp macros, but they are very powerful

Check out this decorator tutorial: http://www.artima.com/weblogs/viewpost.jsp?thread=240808

bigmonachus 2009-04-18 23:22:39

in Lisp: Write a function PER-PIXEL and pass the body as another function. No macro needed.

Rainer Joswig 2009-04-19 04:34:59

Yes, I also fail to understand why this is a good macro example.

kigurai 2009-04-19 07:16:46

Answer 5

+2 A:

See also this question: Pythonic macro syntax

Chris Jester-Young 2009-04-18 23:24:12

-1: This should have been a comment as it doesn't actually answer the question. If it was, I would have upvoted it

Casebash 2010-05-16 08:46:10

Answer 6

+6 A:

Some examples of lisp macros:

ITERATE which is a funny and extensible loop facility
CL-YACC/FUCC that are parser generators that generate parsers at compile time
CL-WHO which allows specifying html documents with static and dynamic parts
Parenscript which is a javascript code generator
Various simple code-wrappers, e.g., error handlers (I have a with-gtk-error-message-handler that executes code and shows GtkMessageDialog if unhandled error occurs), executors (e.g., given a code, execute it in different thread; I have a within-main-thread macro that executes code in different threads; PCall library uses macros to wrap code to be executed concurrently)
GUI builders with macros (e.g., specify widgets hierarchy and widgets' properties and have a macro generate code for creation of all widgets)
Code generators that use external resources during compilation time. E.g., a macro that processes C headers and generates FFI code or a macro that generates classes definitions based on database schema
Declarative FFI. E.g., specifying the foreign structures, functions, their argument types and having macros to generate corresponding lisp structures, functions with type mapping and marshaling code
Continuations-based web frameworks for Common Lisp use macros that transform the code into CPS (continuation passing style) form.

dmitry_vk 2009-04-19 05:45:58

-1: Examples from lisp don't apply very well to Python. If these can be done in Python without macros, then these aren't really use cases for Python are they?

S.Lott 2009-04-20 16:04:56

The only way I see to do most of these in Python is extending the syntax. But that's always true: if you get the language maintainer to extend the language for every feature you might want, that's essentially what macros do. Only with a macro facility, you don't need to fork the language or ask Guido every time.

Ken 2009-04-20 19:04:27

S.Lott: The question is not about applicability of use cases, but about actual use cases. Strictly speaking, when you have eval(), you can do everything without macros. I think that such kind of an argument is counter-productive.I do not think that every one of mentioned examples can be done in Python without losing important features (e.g., minimal/small runtime overhead, compile-time error detection, integration with the rest of the language).

dmitry_vk 2009-04-20 20:57:28

"You can do everything with eval()" is only true if you're willing to put all your code in strings, and write your own parser/translator. But if those are true, you don't even need eval(): any Turing-equivalent language is sufficient.

Ken 2009-04-21 15:18:32

Ken: it is possible to have eval without parser. Some lisps (e.g., newlisp) have F-Exprs. Fexpr is a kind of function that accepts unevaluated arguments as expressions (AST subtrees) and it can decide what to do with them: eval, change and eval, discard, etc. Of course, there are huge problems with fexprs.

dmitry_vk 2009-04-25 10:45:55

The other case being over looked here is early/eager evaluation at compile time. As dmitry-vk mentions in his answer, a parser library that generates parser state machines (very costly) at bytecode-compilation-time. python doesn't "compile" in the traditional sense, but it does convert source to bytecode and then caches it. It would be awfully useful to cache those expensive state machines.

Aaron 2009-04-29 01:11:26

Answer 7

+1 A:

I don't think Python needs macros, because they are useful for 2 things:

Creating a DSL or more eloquent syntax for something (Lisp LOOP macro is a nice example). In this case, Python philosophy decided against it deliberately. If there is some explicit notation you're missing, you can always ask for a PEP.
Making things faster by precomputing things at compile time. Python isn't oriented to speed, so you can always use a function instead.

I am not saying macros are wrong, just that they don't fit Python philosophy. You can always do without them without much code duplication, because you have duck typing and operator overloading.

And as a side note, I would much rather see Lisp's restarts in Python than macros.

2009-04-19 07:05:08

The "Domain" part in Domain Specific Language does not mean a new, stupider way of writing "for" loops.http://domaindrivendesign.org/

vsedach 2010-03-14 21:47:39

So Python's built-in macro facility is the PEP? :-)

Domingo Galdos 2010-08-28 10:21:42

Answer 8

+1 A:

Read "The Lambda Papers" so you might find out generally why one would take advtage of macros at all.

You should start with ‘AIM-353 Lambda:The Ultimate Imperative’ and follow it with ‘AIM-443 Lambda: The Ultimate GOTO’. Both may be found here:

http://library.readscheme.org/page1.html

grettke 2009-06-11 19:37:34

Answer 9

+2 A:

Here's one real-world example I came across that would be trivial with macros or real metaprogramming support, but has to be done with CPython bytecode manipulation due to absence of both in Python:

http://www.aminus.net/dejavu/chrome/common/doc/2.0a/html/intro.html#cpython

This is how the problem is solved in Common Lisp using a combination of regular macros, and read-macros to extend the syntax (it could have been done without the latter, but not the former):

http://clsql.b9.com/manual/csql-find.html

The same problem solved in Smalltalk using closures and metaprogramming (Smalltalk is one of the few single-dispatch OO languages that actually gets message passing right):

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02096.html

Here I tried to implement the Smalltalk approach in Common Lisp, which is a good illustration of how metaprogramming is poorly supported in the latter:

http://carcaddar.blogspot.com/2009/04/closure-oriented-metaprogramming-via.html

vsedach 2010-03-14 22:28:58

ansaurus

tags:

views:

answers:

Python Macros: Use Cases?

related questions