Fate of lambda, Functional Programming in Python...

[Chas Emerick]

On Aug 20, 2004, at 3:05 PM, python-list-request at python.org wrote:

> Nobody is talking about removing the ability to pass functions, just
> the actual "lambda" form.
>
> You can still build a GUI by doing
>
> def spam(stuff):
>   def eggs(parrot):
>     return 5+parrot
>   return eggs
>
> You just can't do
>
> def spam(stuff):
>   return lambda foo: 5+parrot
>
>
> I can't think of a situation where you _really_ need the second (and
> much more limited) form.

Well, there's a couple issues here.  First, I'd rather see the ability 
to do a multiline lambda form.  I'm still not clear on why that wasn't 
dropped in from the start.

But even given the way things are now, lambdas are not just a slight 
reordering of syntax -- they're sometimes the only way to get things 
done quickly and cleanly.  Especially in UI's and in certain simulation 
environments, being able to build up a function table of super-simple 
functions mapped to particular environment parameters is critical.  
Having to explicitly define these sorts of things is a huge pain.  A 
good corollary to python lambdas seems to be anonymous classes in Java, 
especially in a Swing application (the ugly, very gimpy cousin of the 
lambda).  If anonymous classes weren't available in Java, Swing would 
be even worse than it is already; python without lambdas would be a 
huge loss to the language IMO.

And finally, with respect to the spirit of your final comment: just 
because you don't __need__ a more concise, clearer, and easier-to-use 
form doesn't mean that that form has no use, or that switching to a 
'lesser' approach (at least within a restricted usage context) has no 
costs associated with it.

I did find something about GvM's stance towards lambdas and FP in 
general, from http://www.amk.ca/python/writing/gvr-interview.html:

> Sometimes I've been too quick in accepting contributions, and later 
> realized that it was a mistake. One example would be some of the 
> functional programming features, such as lambda functions. lambda is a 
> keyword that lets you create a small anonymous function; built-in 
> functions such as map, filter, and reduce run a function over a 
> sequence type, such as a list.
>
> In practice, it didn't turn out that well. Python only has two scopes: 
> local and global. This makes writing lambda functions painful, because 
> you often want to access variables in the scope where the lambda was 
> defined, but you can't because of the two scopes. There's a way around 
> this, but it's something of a kludge. Often it seems much easier in 
> Python to just use a for loop instead of messing around with lambda 
> functions. map and friends work well only when there's already a 
> built-in function that does what you want.

This is really funny to me, because it seems like Guido is saying, 
essentially, "Python doesn't have proper closures, therefore lambdas 
form a temptation that can't really be fulfilled right now, therefore 
[given the current rumormill] we should get rid of lambdas."  I suppose 
it would be silly to ask why the premise of this line of thought 
shouldn't be changed, instead of throwing the baby out with the 
bathwater.  There's been plenty of discussions about closures and 
python, so I suppose there's no need to kill that topic again.

-- Chas Emerick