A critic of Guido's blog on Python's lambda

[Petr Prikryl]

"Chris Uppal" wrote...
> Alex Martelli wrote:
>
> > I think it's reasonable to make a name a part of functions, classes and
> > modules because they may often be involved in tracebacks (in case of
> > uncaught errors): to me, it makes sense to let an error-diagnosing
> > tracebacks display packages, modules, classes and functions/methods
> > involved in the chain of calls leading to the point of error _by name_.
[...]
> E.g. consider the Smalltalk code (assumed to be the body of a method):
>
>     aCollection
>         do: [:each |
>             each > 0 ifTrue: [^ true]].
>     ^ false.
>
> which iterates over a collection checking to see if any element is > 0. If
so
> then the method answers true ("^" -- spelled "return" in Java), otherwise
it
> answers false.  In that code,
>     [^ true]
> is syntactically and semantically an anonymous function, which is only
invoked
> if the antecedent is true (in point of fact the compiler inlines that
function
> away but I don't think that's relevant here).  The passage beginning
>         [:each | ...
> and reaching to the matching ] is also an anonymous function with one
parameter
> (each) which is applied to each element of the collection in turn.  (In
this
> case it really is an anonymous function, even at the implementation
level.)
> What "name" would you give to either of them ?  I don't believe that /any/
name
> is possible, and certainly that no name is desirable.

        for element in aCollection:
            if element > 0:
                return True
        return False

And adding "def test(aCollection):" does not make it more complex,
in my opinion. And possibly, the chunk of code may be written
in some other way, more Pythonically. Maybe the attempt to
rewrite programs from other languages into Python and
the effort to use the same "tricks" like in the original program,
causes the cry for preserving lambda in future Python.

pepr