[Python-Dev] Extended Function syntax

Moore, Paul Paul.Moore@atosorigin.com
Thu, 30 Jan 2003 10:12:52 -0000


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.