[Python-Dev] defmacro (was: Anonymous blocks)

[Jim Jewett]

Guido:

> My problem with macros is actually more practical: Python's compiler
> is too dumb. I am assuming that we want to be able to import macros
> from other modules, and I am assuming that macros are expanded by the
> compiler, not at run time; but the compiler doesn't follow imports ...

Expanding at run-time is less efficient, but it works at least as well
semantically.  If today's alternative is manual cut-n-paste, I would 
still rather have the computer do it for me, to avoid accidental forks.

It could also be done (though not as cleanly) by making macros act as
import hooks.  

import defmacro                # Stop processing until defmacro is loaded.
                                         # All future lines will be
preprocessed by the
                                         # hook collection
...
from defmacro import foo   # installs a foo hook, good for the rest of the file

Michael Chermside:
>> I think it would be useful if we approached it like this: either what
>> we want is the full power of macros (in which case the syntax we choose
>> should be guided by that choice), or we want LESS than the full power
>> of macros. If we want less, then HOW less?

>> In other words, rather than hearing what we'd like to be able to DO
>> with blocks, I'd like to hear what we want to PROHIBIT DOING with
>> blocks. I think this might be a fruitful way of thinking about the
>> problem which might make it easier to evaluate syntax suggestions. And
>> if the answer is that we want to prohibit nothing, then the right
>> solution is macros.

> I'm personally at a loss understanding your question here. Perhaps you
> could try answering it for yourself?

Why not just introduce macros?  If the answer is "We should, it is just 
hard to code", then use a good syntax for macros.  If the answer is
"We don't want 

    xx sss (S\<!   2k3 ]

to ever be meaningful", then we need to figure out exactly what to 
prohibit.  Lisp macros are (generally, excluding read macros) limited 
to taking and generating complete S-expressions.  If that isn't enough
to enforce readability, then limiting blocks to expressions (or even
statements) probably isn't enough in python.

Do we want to limit the changing part (the "anonymous block") to
only a single suite?  That does work well with the "yield" syntax, but it
seems like an arbitrary restriction unless *all* we want are resource 
wrappers.

Or do we really just want a way to say that a function should share its
local namespace with it's caller or callee?  In that case, maybe the answer
is a "lexical" or "same_namespace" keyword.  Or maybe just a recipe to make
exec or eval do the right thing.

def myresource(rcname, callback, *args):
    rc=open(rcname)
    same_namespace callback(*args)
    close(rc)

def process(*args):
    ...

...
if __name__ == '__main__':
     myresource("file1", process, arg1, arg2)