From: Samuele Pedroni [mailto:pedronis@bluewin.ch]
the first candidate would be a generalization of 'class' (although that make it redundant with 'class' and meta-classes) so that
KEYW-TO-BE kind name [ '(' expr,... ')' ] [ maybe [] extended syntax ]: suite
would be equivalent to
name = kind(name-as-string,(expr,...),dict-populated-executing-suite)
[fixed up to exclude the docstring, as per the followup message] I like this - it's completely general, and easy to understand. Then again, I always like constructs defined in terms of code equivalence, it seems to be a good way to make the semantics completely explicit. The nice thing, to me, is that it solves the immediate problem (modulo a suitable "kind" to work for properties), as well as being extensible to allow it to be used in more general contexts. The downside may be that it's *too* general - I've no feel for how it would look if overused - it might feel like people end up defining their own application language.
the remaining problem would be to pick a suitable KEYW-TO-BE
"block"? Someone, I believe, suggested reusing "def" - this might be nice, but IIRC it won't work because of the grammar's strict lookahead limits. (If it does work, then "def" looks good to me). If def won't work, how about "define"? The construct is sort of an extended form of def. Or is that too cute? By the way, can I just say that I am +1 on Michael Hudson's original patch for [...] on definitions. Even though it doesn't solve the issue of properties, I think it's a nice solution for classmethod and staticmethod, and again I like the generality. Paul.