Guido writes:
> 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
> (that happens at run time) so there's no mechanism to tell the
> compiler about the new syntax. And macros that don't introduce new
> syntax don't seem very interesting (compared to what we can do
> already).
That's good to hear. It expresses fairly clearly what the challenges
are in implementing macros for Python, and expressing the challenges
makes it easier to attack the problem. My interest comes because some
recent syntax changes (generators, generator expressions) have seemed
to me like true language changes, but others (decorators, anonymous-blocks)
to me just cry out "this would be easy as a macro!".
I wrote:
> 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.
Guido replied:
> I'm personally at a loss understanding your question here. Perhaps you
> could try answering it for yourself?
You guys just think too fast for me. When I started this email, I replied
"Fair enough. One possibility is...". But while I was trying to condense
my thoughts down from 1.5 pages to something short and coherent (it takes
time to write it short) everything I was thinking became obscelete as
both Paul Moore and Jim Jewett did exactly the kind of thinking I was
hoping to inspire:
Paul:
> What I feel is the key concept here is that of "injecting" code into a
> template form (try...finally, or try..except..else, or whatever)
[...]
> Specifically, cases where functions aren't enough. If I try to
> characterise precisely what those cases are, all I can come up with is
> "when the code being injected needs to run in the current scope, not
> in the scope of a template function". Is that right?
Jim:
> 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.
[...]
> 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.
My own opinion is that we DO want macros. I prefer a language have a few,
powerful constructs rather than lots of specialized ones. (Yet I still
believe that "doing different things should look different"... which is
why I prefer Python to Lisp.) I think that macros could solve a LOT of
problems.
There are lots of things one might want to replace within macros, from
identifiers to punctuation, but I'd be willing to live with just two of
them: expressions, and "series-of-statements" (that's almost the same as
a block). There are only two places I'd want to be able to USE a macro:
where an expression is called for, and where a series-of-statements is
called for. In both cases, I'd be happy with a function-call like syntax
for including the macro.
Well, that's a lot of "wanting"... now I all I need to do is invent a
clever syntax that allows these in an elegant fashion while also solving
Guido's point about imports (hint: the answer is that it ALL happens at
runtime). I'll go think some while you guys zoom past me again. <wink>
-- Michael Chermside
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
