Re: anonymous blocks vs scope-collapse
Michael Hudson:
This proposal seems a bit like an effort to make generators good at doing something that they aren't really intended -- or dare I say suited? -- for.
I think it is more an effort to use the right keyword, which has unfortunately already been claimed by generators (and linked to iterators). yield is a sensible way for code to say "your turn, but come back later". But at the moment, it means "I am producing an intermediate value", and the way to call that function is to treat it as an iterator (which seems to imply looping over a closed set, so don't send in more information after the initial setup). Should we accept that "yield" is already used up, or should we shoehorn the concepts until they're "close enough"?
So, here's a counterproposal!
with expr as var: ... code ...
is roughly:
def _(var): ... code ... __private = expr __private(_)
...
The need for approximation in the above translation is necessary because you'd want to make assignments in '...code...' affect the scope their written in,
To me, this seems like the core requirement. I see three sensible paths: (1) Do nothing. (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. (3) Add macros. We still have to figure out how to limit their obfuscation. Attempts to detail that goal seem to get sidetracked. -jJ
(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/)
participants (2)
-
Guido van Rossum
-
Jim Jewett