Anonymus functions revisited

[Antoon Pardon]

Op 2005-03-22, Diez B. Roggisch schreef <deetsNOSPAM at web.de>:
>> 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.

I don't understand why people always say short named functions are a
good replacement. IMO list comprehensions and generator expressions
use lambda's in disguise. When we write something like
[x * x for x in some_iterator], nobody seems to have problems that
we just write an expression here and nobody is argueing that we
should define a short function. However when people need the
same kind of semantics in their function, being an expression that
is being reevaluated with different values, for which lambda is the
natural candidate, suddenly we should use short named functions.

Can someone who thinks this way, please explain why this is acceptable

  [ x * x for x in some_iterator ]

But this is not

  map(lambda x: x * x, some_iteraror)

and should be replaced with

  def sqr(x): return x * x
  map(sqr , some_iterator)

-- 
Antoon Pardon