From: "Andrew McGregor" <andrew@indranet.co.nz>
Someone else suggested a sufficiently extensible parser, if I follow their intent, and I agree entirely. In a sense, a macro system is just one possible interface to such an extensible parser.
the problem is that getting that one interface right for user consumption is darn hard and citing Guido about macros in the thread I have referred to (that I hope you have read): "I've considered it, and rejected it. That doesn't mean you shouldn't bring it up, but I expect it would turn Python into an entirely different language."
I also think that if metaclasses can be pythonic, there's a pythonic way to do macros too, but if consensus is against that, then let them simply be an implementation detail of Minimal Python.
The issue is that using macros as a tool risks to trigger a debate on how to get them right and while in Lisp adding some form of macros is a no-brainer, this is not case for Python. So if they do not show to be inavoidable better leave the idea alone. An extensible parser with only a programmable interface can do the trick if necessary. If you want a debate about the pythonicity of macros and possible implementations of them IMO comp.lang.python is probably a better place. Honestly I don't hold my position because I dislike macros, I like macros in Common Lisp, I have thought about adding macros to Python and have partecipated to some debates about the issue. regards