[Python-Dev] Extended Function syntax (original) (raw)

Guido van Rossum guido@python.org
Thu, 30 Jan 2003 21:09:01 -0500

[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: interface.interface I(J,K): 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/)