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

Petr Prikryl prikryl at skil.cz
Wed May 10 08:30:38 CEST 2006

"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
> then the method answers true ("^" -- spelled "return" in Java), otherwise
> answers false.  In that code,
>     [^ true]
> is syntactically and semantically an anonymous function, which is only
> if the antecedent is true (in point of fact the compiler inlines that
> 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
> (each) which is applied to each element of the collection in turn.  (In
> case it really is an anonymous function, even at the implementation
> What "name" would you give to either of them ?  I don't believe that /any/
> 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.


More information about the Python-list mailing list