> 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 -- http://mail.python.org/mailman/listinfo/python-list