Securing a future for anonymous functions in Python

[Jacek Generowicz]

"Anna" <annaraven at gmail.com> writes:

> Jacek Generowicz wrote:
> > "Anna" <annaraven at gmail.com> writes:
> >
> > > With class and def, I at least have a *name* to start with - class
> > > Square pretty obviously is going to have something to do with
> > > geometric shapes, I would hope (or maybe with boring people...).
> >
> > Or maybe with multiplying something by itself. Or maybe the author
> > made some changes in his program, and forgot to rename the class
> > sensibly, and the class' functionality has nothing to do with squares
> > of any sort any more. Or maybe he felt the name "Square" was very
> > appropriate for something else in his program and inadvertently gave
> > the same name to two different entities thereby clobbering the one
> > whose use was intended at this point.
> 
> Idjits abound. ;-)

Yup ... which is one reason why lambda is so useful. Everything there
is to know about it is right in front of your eyes. There is no chance
that some idjit changed the meaning of lambda, or the code which
appears within it (unless that refers to some external names, of
course).

> > So, IIUC, you consider
> >
> >    def add_one(x):
> >        return x+1
> >
> >    map(add_one, seq)
> >
> > to be clearer than
> >
> >    map(lambda x:x+1, seq)
> 
> Completely, totally, and unambiguously:

Curious. It's very much the other way around for me.

> the version with the defined function is immediately clear to me;
> the version with the lambda is decipherable, but requires
> deciphering (even at 2nd and 3rd glance).  But first, wouldn't
> something like:
> 
> [x+1 for x in seq]
> 
> be even clearer?

I'm glad you mentioned that. My next question was going to be
something along the lines of what you think of the equivalent list
comprehension, which is spectacularly devoid of any names to give you
any hints whatsoever.

As to whether it is clearer. That depends. I would venture to suggest
that, given a pool of laboratory rats with no previous exposure to
Python, more of them would understand the map-lambda than the list
comprehension. 

There are no words in the list comprehension at all (besides the
common "seq"): it's all syntax. Even if "map" and "lambda" ring no
bells by association with anything you might have learned outside of
Python, they sure are a lot easier to look up in the documentation.

> Given an example more complex (which you must admit, lambdas usually
> are)

Well, they can't be _that_ much more complex in Python :-) But I'll
grant you, they are often more complex that the one above.

> - the name of the function is something my brain can hold on to to
> represent the group of operations; where with the lambda, I need to
> mentally go through each operation each time I try to read it. And the
> more complex f is, the harder time I have holding it all in my head
> while I figure out how to get from the beginning value x to the ending
> value f(x). lambda is an O(N*N) problem for my brain.

Fair enough. If I understand the code just by looking at it, then I
prefer to see it inline. If its meaning isn't obvious immediately,
then I'd go for the named function too. But I still value the ability
to inline-define the function while developing ... even if the inline
function will be outlined in the final product.

But, how do you feel about the individual lines of code in the body of
a multi-line function? They don't have individual names.

> I could see someone more mathematically-minded being happier with
> lambda. It's not, after all, the word "lambda" itself;

Aaah ... you did suggest (upthread) that it was the word itself which
gave you problems ... which is what piqued my interest.