[Guido van Rossum]
Actually I was attempting to find a solution not just for properties but for other situations as well. E.g. someone might want to define capabilities, or event handlers, or ...
[Greg Ewing]
But anyway, here's another idea:
def foo as property: def __get__(self): ... def __set__(self, x): ...
[Guido van Rossum]
I don't like things that reuse 'def', unless the existing 'def' is a special case and not just an alternative branch in the grammar.
I think Greg's idea ("as" or "is") could satisfy these conditions well (generic solution, and unadorned "def" as special case).
A standard function definition (simple, unadorned "def") is equivalent to:
def f as function: suite
In this syntax, where does the list of formal parameters go? Also, this requires that the scope rules for the suite are exactly as they currently are for functions (including references to non-locals). 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.
A standard method definition is as above, or if a distinction is required or useful it could be equivalent to:
def m(self) as method: suite
OK, I can buy that. I've got a little bit of philosophy on the use of keywords vs. punctuation. While punctuation is concise, and often traditional for things like arithmetic operations, giving punctuation too much power can lead to loss of readability. (So yes, I regret significant trailing commas in print and tuples -- just a little bit.) So I can see the attraction of placing "as foo, bar" instead of "[foo, bar]" between the argument list and the colon.
This syntax could be used to remove a recent wart, making generators explicit:
def g as generator: suite
Of course, it would be a syntax error if the generator suite didn't contain a "yield" statement.
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.
This syntax has aesthetic appeal. I know nothing about its implementability.
That's too bad, because implementabilty makes or breaks a language feature.
What namespace these new modifier terms would live in, I also don't know. The syntax proposal reads well and seems like it could be a good general-purpose solution.
The devil is in the namespace details. Unless we can sort those out, all proposals are created equal. --Guido van Rossum (home page: http://www.python.org/~guido/)