No macros in Python

[Bengt Richter]

On Mon, 16 Dec 2002 00:35:15 GMT, Courageous <jkraska at san.rr.com> wrote:

>
>>Hmm, that's called "unhygienic macros" and is widely considered a bad
>>idea. 
>
>I know what unhygienic macros are. One way around this flaw might be
>to create a context in which the enclosing namespace is made available
>but not the default. This would allow a specific and deliberate
>manipulation of the enclosing namespace, but avoid accidental ones.
>I'm just sort of thinking out loud here.
if locals() could take an argument, and when supplied with an argument
would return a proxy object that would support attribute access, then
you could write
    locals(1).x = locals(1).y + 123
and it would mean operate in the enclosing namespace with the named variables.
    locals(0).x = locals(0).y + 123
would be a long spelling of
    x = y + 123
(Obviously you could also write
    locals(1).x = locals(2).y + 123
or other combinations)

Either way, if x were previously unbound, it would get bound in the selected scope.
Considering all the nesting levels from local to global, you could also count
inwards starting with globals at
    locals(-1).x = 123
which wouldn't require a global declaration.

>
>Of course, for all I know, there's a way to grab the stack and get
>the invokers locals already, if you really insist on this. Is there?
>
You can read them, but I don't know how to write them. But I guess a
debugger has to be able to, so there should be a way.

>C//
>
>p.s. the other problem you talked about could be solved by something
>that looks like a function invocation, but is actually a lexical
>closure around the variables being "passed" to the "function". This
>would require being able to determine at invocation time what type
>the target was: a real function, or this other thing.
>
>

Regards,
Bengt Richter