Velocity Reviews > lambda in list comprehension acting funny

# lambda in list comprehension acting funny

Daniel Fetchinson
Guest
Posts: n/a

 07-11-2012
funcs = [ lambda x: x**i for i in range( 5 ) ]
print funcs[0]( 2 )
print funcs[1]( 2 )
print funcs[2]( 2 )

This gives me

16
16
16

When I was excepting

1
2
4

Does anyone know why?

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Colin J. Williams
Guest
Posts: n/a

 07-11-2012
On 11/07/2012 2:41 AM, Daniel Fetchinson wrote:
> funcs = [ lambda x: x**i for i in range( 5 ) ]
> print funcs[0]( 2 )
> print funcs[1]( 2 )
> print funcs[2]( 2 )
>
> This gives me
>
> 16
> 16
> 16
>
> When I was excepting
>
> 1
> 2
> 4
>
> Does anyone know why?
>
> Cheers,
> Daniel
>
>

I don't understand why you would expect 1, 2, 4.

Perhaps parentheses will help the order of evaluation:

funcs = [(lambda x: x**i) for i in range( 5 )]

This gives:
1
16
81

Colin W.

Ian Kelly
Guest
Posts: n/a

 07-11-2012
On Wed, Jul 11, 2012 at 4:28 AM, Colin J. Williams <(E-Mail Removed)> wrote:
> I don't understand why you would expect 1, 2, 4.

Because:

funcs[0](2) == 2 ** 0 == 1
funcs[1](2) == 2 ** 1 == 2
funcs[2](2) == 2 ** 2 == 4

> Perhaps parentheses will help the order of evaluation:
>
> funcs = [(lambda x: x**i) for i in range( 5 )]
>
> This gives:
> 1
> 16
> 81

No, that gives 16, 16, 16 just like the original. I don't understand
why you would expect 1, 16, 81, unless you have misread the code.

woooee
Guest
Posts: n/a

 07-11-2012
You should not be using lambda in this case
..for x in [2, 3]:
.. funcs = [x**ctr for ctr in range( 5 )]
.. for p in range(5):
.. print x, funcs[p]
.. print

Guest
Posts: n/a

 07-11-2012
Exactly. It's threads like these which remind me why I never use lambda. I would rather give a function an explicit name and adhere to the familiar Python syntax, despite the two extra lines of code. I don't even like the name "lambda". It doesn't tell you what it is (unless you're John McCarthy), a function that you won't re-use and so you don't really need to give ita persistent name.

I haven't seen any lambdas in any Python library code, or in any of the third-party modules I use (numpy, matplotlib, Biopython). Do they exist? Because I have not been forced to do so, I haven't retained a space in the topdrawer of my programming brain for lambda.

I know the historical reason that Python ended up with lambda, it was requested by people in the Lisp community. While I appreciate some of the Lisp-like features which did find their way into Python (especially being able to treat code as data, and functions as objects), I've found that lambda does nothing for me.

Hans Mulder
Guest
Posts: n/a

 07-11-2012
On 11/07/12 20:38:18, woooee wrote:
> You should not be using lambda in this case
> .for x in [2, 3]:
> . funcs = [x**ctr for ctr in range( 5 )]
> . for p in range(5):
> . print x, funcs[p]
> . print

The list is called "funcs" because it is meant to contain functions.
Your code does not put functions in the list, so it doesn't do what
he wants.

He could do:

funcs = []
for i in range(5):
def f(x):
return x**i
funcs.append(f)
print funcs[0]( 2 )
print funcs[1]( 2 )
print funcs[2]( 2 )

..... and it will print 16, 16, 16 for the same reason as the lambda
version. On the other hand, this does what he wants:

funcs = []
for i in range(5):
def f(x, i=i):
return x**i
funcs.append(f)
print funcs[0]( 2 )
print funcs[1]( 2 )
print funcs[2]( 2 )

The lambda keyword is a red herring. The question is really about
functions, and how they handle non-local variables. The good news
is that 'lambda' and 'def' work exactly the same in that regards.
So once you understand the finer points about 'def', you no longer
have a reason to avoid 'lambda'.

Hope this helps,

-- HansM

Steven D'Aprano
Guest
Posts: n/a

 07-11-2012
On Wed, 11 Jul 2012 11:38:18 -0700, woooee wrote:

> You should not be using lambda in this case
> .for x in [2, 3]:
> . funcs = [x**ctr for ctr in range( 5 )]
> . for p in range(5):
> . print x, funcs[p]
> . print

If you change the requirements, it's always easy to solve problems. But
it is the wrong problem that you have solved.

The problem we have been asked to solve is to create a sequence of
function objects, so that they can be called later, when needed, *not* to
pre-calculate the results.

In this case, the most obvious solution is to store a local variable in
each function object with the value you want.

funcs = [(lambda x, i=i: x**i) for i in range(5)]

creates a list of five functions:

lambda x, i=0: x**i
lambda x, i=1: x**i
lambda x, i=2: x**i
and so on.

In this case, each function has two local variables, x and i, with i
having a default value. The function parameter i is bound to the value of
i when the function was created.

Because parameter defaults are calculated once, when the function is
created, this causes the value of i to stick to the newly created
function, and we get the result we need.

What happens if you don't use a parameter with a default value?

funcs = [(lambda x: x**i) for i in range(5)]

In this case, each function body contains one local variable, x, and one
non-local or global variable, i.

Because i is a non-local, the function doesn't store a value for it.
Instead, the function stores a lump of data pointing to just enough of
the environment to fetch the current value of the non-local i when
needed. Since all five functions are in the same environment, they all
see the same value of i when you call them, regardless of what the value
of i was when they were created.

This is little different from doing this:

i = 1
def f1(x): return x**i

i = 2
def f2(x): return x**i

i = 3
def f3(x): return x**i

Is there any surprise that all three functions return the same value?
They all point to the same global variable i. I'm not sure what it is
about lambda that fools people into thinking that it is different (I've
even been fooled myself!) but it is not.

--
Steven

Steven D'Aprano
Guest
Posts: n/a

 07-12-2012

> Exactly. It's threads like these which remind me why I never use
> lambda. I would rather give a function an explicit name and adhere to
> the familiar Python syntax, despite the two extra lines of code.

lambda is familiar Python syntax, or at least it should be if you
consider yourself an expert Python programmer.

And besides, this is not a problem with lambda. You get the *exact* same
problem with "ordinary" function definitions. Of course you do -- lambdas
*are* ordinary functions, they just have a more compact syntax.

funcs = []
for i in range(5):
def pwr(x):
return x**i
print("Testing 3**%d:" % i, pwr(3))
funcs.append(pwr)

for j in range(5):
print("Expected", 3**j, "got", funcs[j](3))

gives you *exactly* the same issue as with the lambda. This is not a
problem with lambdas, this is a scoping issue.

> I don't even like the name "lambda". It doesn't tell you what it is

Whereas "def" does?

If you can learn that "def" defines a function (as opposed to a class, a
module, or anything else really) than it's not that hard to learn that
"lambda" also defines a function.

Although I do wonder whether people would be less scared of lambda, and
less likely to imagine that it creates something with strange mysterious
properties different from "regular functions", if the keyword was called

> (unless you're John McCarthy), a function that you won't re-use and so
> you don't really need to give it a persistent name.

Whether or not a function has a persistent name has nothing to do with
reuse. Anonymous functions can be reused. The driving motivation for
lambdas is for callback functions, which are frequently reused, but you
don't need or want to fill your global namespace up with potentially
hundreds of callback functions.

Lambda syntax is only incidentally good for saving a line or two. If the
only benefit of lambda was to save a line of code, that would be stupid.
The real reason for lambda is to avoid polluting your namespace with
unnecessary names.

Python allows us to easily and simply use anonymous strings, anonymous
ints, anonymous objects of all types. Why should functions be treated as
second-class?

> I haven't seen any lambdas in any Python library code, or in any of the
> third-party modules I use (numpy, matplotlib, Biopython). Do they
> exist? Because I have not been forced to do so, I haven't retained a
> space in the top drawer of my programming brain for lambda.

There are over 800 uses of lambda in the standard library:

[steve@ando ~]\$ cd /usr/local/lib/python3.2
[steve@ando python3.2]\$ grep lambda *.py */*.py | wc -l
829

(although some of the above are comments, doctests, etc.)

See, for example, configparser, decimal, functools, gettext, inspect,
pydoc, symtable, uuid, and others. pydoc and idlelib in particular make
heavy use of lambda, and the test suite is overflowing with them -- over
600 uses in total.

--
Steven

Dennis Lee Bieber
Guest
Posts: n/a

 07-12-2012
<(E-Mail Removed)> declaimed the following in
gmane.comp.python.general:

> I know the historical reason that Python ended up with lambda, it was requested by people in the Lisp community. While I appreciate some of the Lisp-like features which did find their way into Python (especially being able to treat code as data, and functions as objects), I've found that lambda does nothing for me.

It can be useful when defining callbacks for GUIs that need a
predefined argument... eg; a calculator application: 10 buttons for 0-9.
Why define 10 separate callbacks when you only need one callback with a
parameter containing the numeric value for the button.

lambda x=#: number_button_callback(x)

where # is the (integral) value of the specific button.

{non sequitur: I still recall my archaic C++ class with the OOAD
assignment of designing said calculator -- we never had to implement
one, just design the basic classes/methods/attributes [on 3x5 cards] for
a four-banger. I managed to persuade the team I was on that an RPN
calculator would be simpler to (potentially) implement... And THEN
persuaded them to NOT use the equivalent of an ALU class, but to put the
math work into each operation button... Justification when presented to
class: one could turn that four-banger into a scientific [or financial]
[and of course, buttons on screen] rather than having to rewrite an
"ALU" class to understand all functions.}
--
Wulfraed Dennis Lee Bieber AF6VN
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

Daniel Fetchinson
Guest
Posts: n/a

 07-12-2012
>> You should not be using lambda in this case
>> .for x in [2, 3]:
>> . funcs = [x**ctr for ctr in range( 5 )]
>> . for p in range(5):
>> . print x, funcs[p]
>> . print

>
> If you change the requirements, it's always easy to solve problems. But
> it is the wrong problem that you have solved.
>
> The problem we have been asked to solve is to create a sequence of
> function objects, so that they can be called later, when needed, *not* to
> pre-calculate the results.
>
> In this case, the most obvious solution is to store a local variable in
> each function object with the value you want.
>
> funcs = [(lambda x, i=i: x**i) for i in range(5)]
>
> creates a list of five functions:
>
> lambda x, i=0: x**i
> lambda x, i=1: x**i
> lambda x, i=2: x**i
> and so on.
>
> In this case, each function has two local variables, x and i, with i
> having a default value. The function parameter i is bound to the value of
> i when the function was created.
>
> Because parameter defaults are calculated once, when the function is
> created, this causes the value of i to stick to the newly created
> function, and we get the result we need.
>
> What happens if you don't use a parameter with a default value?
>
> funcs = [(lambda x: x**i) for i in range(5)]
>
> In this case, each function body contains one local variable, x, and one
> non-local or global variable, i.
>
> Because i is a non-local, the function doesn't store a value for it.
> Instead, the function stores a lump of data pointing to just enough of
> the environment to fetch the current value of the non-local i when
> needed. Since all five functions are in the same environment, they all
> see the same value of i when you call them, regardless of what the value
> of i was when they were created.
>
> This is little different from doing this:
>
> i = 1
> def f1(x): return x**i
>
> i = 2
> def f2(x): return x**i
>
> i = 3
> def f3(x): return x**i
>
> Is there any surprise that all three functions return the same value?
> They all point to the same global variable i. I'm not sure what it is
> about lambda that fools people into thinking that it is different (I've
> even been fooled myself!) but it is not.

Thank you Steve!
Precise and clear, as always!

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown