No macros in Python

Mike Meyer mwm at mired.org
Tue Dec 17 00:43:05 EST 2002


bokr at oz.net (Bengt Richter) writes:

> On Sun, 15 Dec 2002 19:03:23 -0500, Lulu of the Lotus-Eaters <mertz at gnosis.cx> wrote:
> ISTM the key issue is being able to write an abbreviation for something
> to be done more than once **within the current scope**.

I think that's *one* of the issues. Sometimes you want to be able to
arrange the context of code that will be executed in the current scope
somewhat. The classic example is the "with-io-redirection" macro:

        macro with-output-to-file "filename":
           print Stuff(), to(), append()
           print to(), "filename"

and then run the suite under "macro" in a context to DTRT.

[ ... ]
> Unless invoked, it would not get executed. To execute it, you could spell the invocation
> like a parameterless function call or it could be an exec variant. But the code would act
> like it got control under an if, as far as scope is concerned.

What I really want to do with this "suite" type object is pass it to
function, possibly along with other suites. That way I can use the
full power of python on the suites and on values they may return.

> Then, to execute the defined foo code suite with **those** x,y,z variables set
> to something specific, just write the foo call as if it were an ordinary function.
> E.g,
> 
>     foo(1, 2, 3)
> 
> would be equivalent to
> 
>     x=1; y=2; z=3
>     foo()
> 
> done in the current scope by 1:1 association with the declared parameter sequence.

Why not just build a closure for all this? You're doing most of the
work anyway. Of course, that means you wind up having the overhead of
a function call.

> Passing a local code seg reference out of scope might raise difficult
> closure issues, so would probably have to be illegal, at first anyway.

That kills the most interesting uses of these things.

> Above I did not propose macros, but I think it might be better than macros
> for Python, and could speed things up for some applications ;-)

I think you've just proposed another special purpose mechanism - like
yield - that handles some of the things that macros can do, but could
be done with something that looked like a real macro system if we had
one.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list