On Fri, Jan 31, 2003, Guido van Rossum wrote:
Aahz:
Guido:
That's all fine and dandy, but then I don't understand how the poor implementation of property is going to extract __get__ etc. from the local variables of the function body after executing it.
Sort of. Each keyword can handle the thunk differently. For the property keyword, it'd be handled more similarly to a class. In fact, class then becomes
def C as class: suite
Um, the whole point of this syntax is that property, synchronized etc. do *not* have to be keywords -- they are just callables.
So the compiler cannot look at what the thunk is used for. We need uniform treatment of all thunks. (Even if it means that the thunk's consumer has to work a little harder.)
I'm not sure I agree with this assertion. I think that there *do* need to be different kinds of thunks. Perhaps it's only necessary for there to be two or three different kinds of generic thunks (at least "creates new local scope" and "does not create new local scope"). Note that what follows after the "as" need not be an actual Python keyword, but it does need to be something significant to the parser/compiler, similar to the way "from __future__" works. I think that requiring thunk types to be built into the language is reasonable. If we're going the generic route, we could do something like this: class C: def foo as (immediate, local) [property]: def __get__(self): ... I suppose we could agree that all thunks create a new local scope and that all thunks get executed immediately (like classes and modules, but unlike functions), but I would prefer to not build that restriction into the syntax. If we don't agree on this (or on some other set of properties that all thunks have), we can't have uniform treatment of thunks as you desire. It occurs to me that "thunk" would make a good keyword if we're adding one. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach