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 =3D =
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4