2006-02-06

Crap, lambda is sticking around

Well, this email has Guido saying that since an alternative to lambda has not been found, that it will just stay. I have to admit I am disappointed.

I was looking forward to lambda going away. First of all, it isn't truly a lambda expression as most people are used to in other languages that have it thanks to the no-statements limitation (although with 'print' becoming a function and the introduction of conditional expressions there are at least two less statement restriction problems). So at least the name is off.

Second, it doesn't provide anything that cannot be reached using a simple named function thanks to functions being first-class. This was originally proposed as the solution for when lambdas went away.

If you look at where lambda tends to be used, I would guess three places: deferred execution, callbacks, and just funky situations. Deferred execution we have the proposed deferred exeuction objects (sparked by Alex Martelli's desire for a methodcaller object along with the existence of operator.itemgetter and attrgetter). Callbacks can use named functions, and so can funky situations.

I mean really, lambda is used when one just does not want to bother to type out and name a simple function. Fine, but what situations does that call for? A common usage is for stuff like the key argument to list.sort(). But that can be handled by a deferred object implementation. And if functional.partial is not powerful enough for those situations of calling a function with arguments later, then perhaps we can tweak so it is.

But if we are going to keep lambda, fine. But I say at least rename it to something like 'expr' or 'expression' so people like me don't forget on occasion about it's restriction. Plus ditch operator.itemgetter and attrgetter since their usefulness kind of goes out the window with lambda sticking around. And obviously both of these are Python 3 suggestions.