Home Original page

No macros in Python

Terry Hancock hancock at anansispaceworks.com
Sun Dec 15 16:57:59 EST 2002 
On Sunday 15 December 2002 12:44 pm,  Courageous  wrote:
> Mike Meyer wrote:
> > Python doesn't have macros. On the other hand, looking at the world
> > through OO glasses rather than S-expression glasses means you don't
> > need macros as often. But the topic comes up at irregular intervals,
> > so someone may eventually come up with a way of doing macros in Python
> > that is right - at which point it'll be added.
> 
> In what way would macros (as I understand them... from C for example)
> improve Python, other than possibly a small improvement in performance?

I'm sure Mike meant "lisp-like macros", not C macros.  Not being a lisper, 
though, I can't say why those would be so indispensible, either. I tend 
toward an OOP style of programming, myself (though I'm not compulsive about 
it).

My impression is that macros would be very like classes with a defined 
__call__ method -- the __init__ defines it, so you can create callable 
instances. Zope's ZSQL Methods and DTML Methods work like this, and I've even 
found a few uses for custom ones. If one uses eval, so that the code to 
define the __call__ method, then ISTM we have basically what lisp macros do 
(as I have understood their description), which is to allow instances of code 
to be treated as data and edited or called at will.   I believe the relevant 
term here is "factory class".

But since, we can use *any* parser, including custom written ones which parse 
other, possibly special purpose languages (e.g. XML-based code like DTML or 
SQL), ISTM that we have more flexibility. OTOH, Lisp may do this more 
transparently than Python does (there's a fair amount of boilerplate in what 
I just described).  Considering that it's an advanced technique in either 
language, though, this complexity doesn't really bother me. If you don't need 
it enough to mess with the boilerplate, maybe it was better to do without it 
anyway. (?)

Maybe "macros" for Python should just be a convenient module providing 
factories that work from Python code, with lisp-like manipulations defined 
for the "parse-tree"?  I'm well out of my depth though, as these are mostly 
just buzzwords to me.  I'm not exactly sure what this would need to do that 
is not already done by eval(), rexec(), etc., but surely there is a defined 
behavior that could be emulated.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

"Some things are too important to be taken seriously"
More information about the Python-list mailing list