[Python-Dev] Re: anonymous blocks vs scope-collapse

Guido van Rossum gvanrossum at gmail.com
Tue Apr 26 18:57:01 CEST 2005

> (2)  Add a way to say "Make this function I'm calling use *my* locals
> and globals."  This seems to meet all the agreed-upon-as-good use
> cases, but there is disagreement over how to sensibly write it.  The
> calling function is the place that could get surprised, but people
> who want thunks seem to want the specialness in the called function.

I think there are several problems with this. First, it looks
difficult to provide semantics that cover all the corners for the
blending of two namespaces. What happens to names that have a
different meaning in each scope? (E.g. 'self' when calling a method of
another object; or any other name clash.) Are the globals also
blended? How? Second, this construct only makes sense for all
callables; you seem to want to apply it for function (and I suppose
methods, whether bound or not), but it makes no sense when the
callable is implemented as a C function, or is a class, or an object
with a __call__ method. Third, I expect that if we solve the first two
problems, we'll still find that for an efficient implementation we
need to modify the bytecode of the called function.

If you really want to pursue this idea beyond complaining "nobody
listens to me" (which isn't true BTW), I suggest that you try to
define *exactly* how you think it should work. Try to make sure that
it can be used in a "statement context" as well as in an "expression
context". You don't need to come up with a working implementation, but
you should be able to convince me (or Raymond H :-) that it *can* be
implemented, and that the performance will be reasonable, and that it
won't affect performance when not used, etc.

If you think that's beyond you, then perhaps you should accept "no" as
the only answer you're gonna get. Because I personally strongly
suspect that it won't work, so the burden of "proof", so to speak, is
on you.

> (3)  Add macros.  We still have to figure out how to limit their obfuscation.
> Attempts to detail that goal seem to get sidetracked.

No, the problem is not how to limit the obfuscation. The problem is
the same as for (2), only more so: nobody has given even a *remotely*
plausible mechanism for how exactly you would get code executed at
compile time. You might want to look at Boo, a Python-inspired
language that translates to C#. They have something they call
syntactic macros: http://boo.codehaus.org/Syntactic+Macros .

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list