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

Jim Jewett jimjjewett at gmail.com
Mon Apr 25 21:34:55 CEST 2005

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)

More information about the Python-Dev mailing list