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.)
But then 'generator' would have to be recognized by the parse as a magic keyword. I thought that the idea was that there could be a list of arbitrary expressions after the 'as' (or inside the square brackets). If it has to be keywords, you lose lots of flexibility.
You allow both. The square brackets operate on the thunk (which is probably all that's needed for classmethod and staticmethod); different kinds of thunk parsing/compiling require keywords:
def C as class: def foo(x) [staticmethod]: return x*2 def bar(self, y) as generator: for i in y: yield self.foo(i) def spam as property [classmethod]: def __get__(cls): ...
I don't think this is a problem we're trying to solve. --Guido van Rossum (home page: http://www.python.org/~guido/)