[Python-Dev] Extended Function syntax

[Guido van Rossum]

[Samuele]
> an alternative (if parseable, I have not fully thought about that)
> would be to leave out the KEYW-TO-BE and try to parse directly
> 
> kind  name [ '(' expr,... ')' ]  [ maybe [] extended syntax ]:
> 
> where kind could be any general expr or better only a qualified name
> that are NOT keywords, so we would possible have:
> 
> property foo:
>  <suite>
> 
> interface.interface I(J,K):
>   <suite>
> 
> all working  as specified like 'class' and with its scope rules.

The problem is that this is much harder for the LL(1) parser;
otherwise I like it fine.  The name being defined (foo and I above)
would be available to the code implementing 'kind', which is useful.

What's still missing is a way to add formal parameters to the thunk --
I presume that J and K are evaluated before interface.interface is
called.  The thunk syntax could be extended to allow this; maybe this
can too.  E.g.:

  e:(x, y):
    S

would create a thunk with two formal parameters, x and y; and when e
calls the thunk, it has to call it with two arguments which will be
placed in x and y.  But this is a half-baked idea, and the syntax I
show here is ambiguous.

> Control flow statements would still have to be added to the language
> one by one (I find that ok and pythonic).

I disagree; there's a number of abstractions like synchronized that
would be very useful to have.

> Also because specifying and implementing implicit thunk with proper
> scoping and non-local return etc does not (to me) seem worth the
> complication.

See my other post.

> About extending or generalizing function 'def' beyond [] extended
> syntax, I don't see a compelling case.

Me neither.

--Guido van Rossum (home page: http://www.python.org/~guido/)