Mike Meyer wrote: > My choice for the non-name token is "@". It's already got magic > powers, so we'll give it more rather than introducing another token > with magic powers, as the lesser of two evils.
Doesn't work. The crux of your change isn't introducing a meaning to @ (and honestly, I prefer _), it's that you change the 'define block' from a compound_stmt (funcdef) (see www.python.org/doc/current/ref/compound.html) to an expression_stmt (expresion). This change would allow some really damn weird things, like: if def _(x,y): return x**2 - y**2 (5,-5): # ?! How would you immediately call this 'lambda-like'?[1] print 'true' else: print 'false' [1] -- yes, it's generally stupid to, but I'm just pointing out what has to be possible. Additionally, Python's indenting Just Doesn't Work Like That; mandating an indent "after where the def came on the previous line" (as you do in your example, I don't know if you intend for it to hold in your actual syntax) wouldn't parse right -- the tokenizer generates INDENT and DEDENT tokens for whitespace, as I understand it. My personal favourite is to replace "lambda" entirely with an "expression comprehension", using < and > delimeters. It just looks like our existing list and generator comprehensions, and it doesn't use 'lambda' terminology which will confuse any newcomer to Python that has experience in Lisp (at least it did me). g = <x**2 with (x)> g(1) == 1 Basically, I'd rewrite the Python grammar such that: lambda_form ::= "<" expression "with" parameter_list ">" Biggest change is that parameter_list is no longer optional, so zero-argument expr-comps would be written as <expr with ()>, which makes a bit more sense than <expr with>. Since "<" and ">" aren't ambiguous inside the "expression" state, this shouldn't make the grammar ambiguous. The "with" magic word does conflict with PEP-343 (semantically, not syntactically), so "for" might be appropriate if less precise in meaning. -- http://mail.python.org/mailman/listinfo/python-list