Anonymus functions revisited

[Diez B. Roggisch]

> Not exactly in fact - unless I messed something. There are 2 problems
> here: a more flexible tuple unpacking, *and* a lambda in disguise.
> Actually, I'd go + 1 for the first, -1 for the second

The proposed syntax from Kay is lambda in disguise. To make it work like
George want it is modifying the unpacking behaviour. Actually while Kay
proposed his syntax as result of the discussion started by George it won't
work for that case. The reason is simply that the lambda form returns a 
tuple, but does not make any revelations about the variable names that
tuple shall be unpacked to.

So they are in fact unrelated - at least if introduced as declared. An
augmentation to fulfill George's wishes could look like this:

[a,b,c for a,b,c: (x,y,z=0)-> x,y,z) in values]

> Yes, one can live without...
> <troll>
> ...and without list comprehensions, __call__ and other special methods,
> descriptors, metaclasses, first class functions, builtin datatypes like
> lists and dicts, exceptions, dynamic typing, garbage collection,  etc
> too. Hurray, let's all happily program in assembly !-)
> </troll>

You are right, but for lambda in its current limited form short, named
functions are a good replacement. I don't want to get rid of lambda - but
since listcomps got introduced, 95% of my usages of them disappeared.

-- 
Regards,

Diez B. Roggisch