Lambda going out of fashion

[Craig Ringer]

On Thu, 2004-12-23 at 15:21, tanghaibao at gmail.com wrote:
> This is NOT true. Functional programming, AFAIKC, is a cool thing, and
> in-fashion, increases productivity & readability, and an indispensable
> thing for a flexible scripting lang.

Couldn't agree more. One of the things I find most valuable about Python
is the ability to use functional style where it's the most appropriate
tool to solve a problem - WITHOUT being locked into a pure-functional
purist language where I have to fight the language to get other things
done.

> The inline/lambda function is
> feature is shared by many lang. which I frequently use,
> MATLAB/R/Python/etc. Well, you can say apply() is 'deprecated' now,
> (which is another functional thing I like), but I am still using it. I
> am not a desperate person who uses higher-order function factory a lot,
> but if lambda keyword is removed, I swear I will not use the python
> anymore.

I also make signficant use of Lambda functions, but less than I used to.
I've recently realised that they don't fit too well with Python's
indentation-is-significant syntax, and that in many cases my code is
much more readable through the use of a local def rather than a lambda.

In other words, I increasingly find that I prefer:

def myfunction(x):
    return x**4
def mysecondfuntion(x):
    return (x * 4 + x**2) / x
make_some_call(myfunction, mysecondfunction)

to:

make_some_call( lambda x: x**4, lambda x: (x * 4 + x**2) / x)

finding the former more readable. The function names are after all just
temporary local bindings of the function object to the name - no big
deal. Both the temporary function and the lambda can be used as
closures, have no impact outside the local function's scope, etc. I'd be
interested to know if there's anything more to it than this (with the
side note that just don't care if my temporary functions are anonymous
or not).

One of the things I love about Python is the ability to mix functional,
OO, and procedural style as appropriate. I can write a whole bunch of
functions that just return the result of list comprehensions, then use
them to operate on instances of an object from a procedural style main
function. In fact, that's often the cleanest way to solve the problem.
The fact that I have that option is something I really like.

As for apply(), while it is gone, the f(*args) extension syntax is now
available so I don't really see the issue. After all, these two are the
same:

def callfunc(function,args):
    return apply(function,args)

and

def callfunc(function,args):
    return function(*args)

its just an (IMO trivial) difference in syntax. I'd be interested in
knowing if there is in fact more to it than this.

--
Craig Ringer