473,699 Members | 2,433 Online

# What are python closures realy like?

Hi,
while writing my last program I came upon the problem
of accessing a common local variable by a bunch of
functions.
I wanted to have a function which would, depending on
the same variable. An OO approach would do but why not
try out closures...
So here is a simplified example of the idea:
common_var = [0]
def f1():
print common_var[0]
common_var[0]=1
def f2():
print common_var[0]
common_var[0]=2
if f == 1:
return f1
if f == 2:
return f2
If you call f1 and f2 from the inside of fun_basket, they
behave as expected, so common_var[0] is modified by
whatever function operates on it.
then f1(); f2() returns 0 and 0. It is not the way one would
expect closures to work, knowing e.g. Lisp make-counter.
Any ideas what's going on behind the scene?
Dec 1 '06 #1
16 1281
On 12/1/06, Karl Kofnarson <ko*******@gmai l.comwrote:
[snip]
common_var = [0]
def f1():
print common_var[0]
common_var[0]=1
def f2():
print common_var[0]
common_var[0]=2
if f == 1:
return f1
if f == 2:
return f2
Everytime you call fun_basket you create another common_var.
then f1(); f2() returns 0 and 0.
Two calls to fun_basket, two different common_var's, two f1's and two
f2's. Each f1/f2 pair have access to a different common_var, so it's
working as expected. To work as you expected, fun_basket should be on
the same block common_var is defined.

--
Felipe.
Dec 1 '06 #2
Karl Kofnarson wrote:
Hi,
while writing my last program I came upon the problem
of accessing a common local variable by a bunch of
functions.
I wanted to have a function which would, depending on
the same variable. An OO approach would do but why not
try out closures...
So here is a simplified example of the idea:
common_var = [0]
def f1():
print common_var[0]
common_var[0]=1
def f2():
print common_var[0]
common_var[0]=2
if f == 1:
return f1
if f == 2:
return f2
If you call f1 and f2 from the inside of fun_basket, they
behave as expected, so common_var[0] is modified by
whatever function operates on it.
then f1(); f2() returns 0 and 0. It is not the way one would
expect closures to work, knowing e.g. Lisp make-counter.
Any ideas what's going on behind the scene?
Python can be read quite literally. "common_var " is a local variable
"def" is a statement that creates a function when it is executed. If
you execute the same def statement twice, two different functions are
created. Running fun_basket twice creates four closures, and the first
two have no relation to the second two. The two sets close over
different cell variables.

If you want to share data between function invokation, you need an
object which persists between calls. You can use a global variable, or
a default argument. But since the value is shared everytime the
function is called, I don't see the value in using a closure. I don't
know lisp very well, but in my mind the whole point of closures is that
you can reference a different unique cell each time.

-MIke

Dec 1 '06 #3
"Karl Kofnarson" <ko*******@gmai l.comwrote in message
news:pa******** *************** *****@gmail.com ...
Hi,
while writing my last program I came upon the problem
of accessing a common local variable by a bunch of
functions.
I wanted to have a function which would, depending on
the same variable. An OO approach would do but why not
try out closures...
So here is a simplified example of the idea:
common_var = [0]
def f1():
print common_var[0]
common_var[0]=1
def f2():
print common_var[0]
common_var[0]=2
if f == 1:
return f1
if f == 2:
return f2
Karl,

Usually when using this idiom, fun_basket would return a tuple of all of the
defined functions, rather than one vs. the other. So in place of:
if f == 1:
return f1
if f == 2:
return f2
Just do
return f1, f2
(For that matter, the argument f is no longer needed either.)

Then your caller will get 2 functions, who share a common var. You don't

And then call z1() and z2() at your leisure - they should have the desired
behavior.

-- Paul
Dec 1 '06 #4
Karl Kofnarson wrote:
Hi,
while writing my last program I came upon the problem
of accessing a common local variable by a bunch of
functions.
I wanted to have a function which would, depending on
the same variable. An OO approach would do but why not
try out closures...
So here is a simplified example of the idea:
common_var = [0]
def f1():
print common_var[0]
common_var[0]=1
def f2():
print common_var[0]
common_var[0]=2
if f == 1:
return f1
if f == 2:
return f2
If you call f1 and f2 from the inside of fun_basket, they
behave as expected, so common_var[0] is modified by
whatever function operates on it.
then f1(); f2() returns 0 and 0. It is not the way one would
expect closures to work, knowing e.g. Lisp make-counter.

Lisp works the same way.

(let ((common_var 0))
(defun f1 ()
(print common_var)
(setf common_var 1))
(defun f2 ()
(print common_var)
(setf common_var 2))
(if (eq f 1)
#'f1
#'f2)))

* (setf (symbol-function 'f1a) (fun_basket 1))

; Converted F1.
; Converted F2.

#<Interpreted Function F1 {5807C9A1}>
* (setf (symbol-function 'f2a) (fun_basket 2))

#<Interpreted Function F2 {5807D409}>
* (f1a)

0
1
* (f2a)

0
2
Any ideas what's going on behind the scene?
Every time you call the function, a new closure is created.
Carl Banks

Dec 1 '06 #5
Karl,
>
Usually when using this idiom, fun_basket would return a tuple of all of the
defined functions, rather than one vs. the other. So in place of:
> if f == 1:
return f1
if f == 2:
return f2
Just do
> return f1, f2
(For that matter, the argument f is no longer needed either.)

Then your caller will get 2 functions, who share a common var. You don't

And then call z1() and z2() at your leisure - they should have the desired
behavior.

-- Paul
Thanks a lot Paul and for the other answers. The things are now
clear to me. In fact, in the Lisp example that I mentioned, you
get a list (or let it be association list) of the internal
functions. Then you can call them separately and they work as
you expect but it's due to the fact only that you got them created
at the same time.
Dec 2 '06 #6

Karl Kofnarson wrote:
Karl,

Usually when using this idiom, fun_basket would return a tuple of all of the
defined functions, rather than one vs. the other. So in place of:
if f == 1:
return f1
if f == 2:
return f2
Just do
return f1, f2
(For that matter, the argument f is no longer needed either.)

Then your caller will get 2 functions, who share a common var. You don't

And then call z1() and z2() at your leisure - they should have the desired
behavior.

-- Paul

Thanks a lot Paul and for the other answers. The things are now
clear to me. In fact, in the Lisp example that I mentioned, you
get a list (or let it be association list) of the internal
functions. Then you can call them separately and they work as
you expect but it's due to the fact only that you got them created
at the same time.
I played around a bit. The following is a 'borg' version in that there
is only one counter shared between all calls of the outer function:
>>def fun_borg_var(in itial_val=0):
.... def borg_var_inc(x= 1):
.... fun_borg_var._n += x
.... return fun_borg_var._n
.... def borg_var_dec(x= 1):
.... fun_borg_var._n -= x
.... return fun_borg_var._n
.... try:
.... fun_borg_var._n = fun_borg_var._n
.... except:
.... fun_borg_var._n = initial_val
.... return (borg_var_inc, borg_var_dec)
....
>>up1, dn1 = fun_borg_var() # get an inc/decrementer
up1(0)
0
>>up1()
1
>>up1()
2
>>dn1()
1
>>dn1()
0
>>dn1()
-1
>>up2, dn2 = fun_borg_var() # get another inc/decrementer
up2(0) # looks like the same _n
-1
>>up2(3)
2
>>up1(3)
5
>>>

Dec 6 '06 #7
I played around a bit. The following is a 'borg' version in that there
is only one counter shared between all calls of the outer function:
>>>def fun_borg_var(in itial_val=0):
... def borg_var_inc(x= 1):
... fun_borg_var._n += x
a drawback with the function attribute approach compared to a real closure
is that the function is no longer a self-contained callable:

def fun_borg_var(in itial_val=0):
def borg_var_inc(x= 1):
fun_borg_var._n += x
return fun_borg_var._n
def borg_var_dec(x= 1):
fun_borg_var._n -= x
return fun_borg_var._n
try:
fun_borg_var._n = fun_borg_var._n
except:
fun_borg_var._n = initial_val
return (borg_var_inc, borg_var_dec)

up1, dn1 = fun_borg_var()

del fun_borg_var # won't need this any more

print up1() # oops!

so you might as well use a good old global variable, and initialize it as
usual.

</F>

Dec 6 '06 #8
Karl Kofnarson wrote:
>
I wanted to have a function which would, depending on
the same variable. An OO approach would do but why not
try out closures...
I know that everyone will say that Python is a "multi-paradigm"
language and that one should feel free to use whatever technique seems
appropriate to solve the problem at hand, but it seems to me that
there's been an explosion in nested function usage recently, with lots
of code snippets showing them off either in the context of a debugging
exercise or as a proposed solution to a problem, and yet in many cases
their usage seems frivolous in comparison to plain old object-oriented
techniques.

I'm not pointing the finger at you here, Karl, since you seem to be
experimenting with closures, but why are they suddenly so fashionable?
Haven't the features supporting them existed in Python for a few
versions now? Don't people want to write classes any more?

Intrigued,

Paul

Dec 6 '06 #9
Paul Boddie wrote:
I know that everyone will say that Python is a "multi-paradigm"
language and that one should feel free to use whatever technique seems
appropriate to solve the problem at hand, but it seems to me that
there's been an explosion in nested function usage recently, with lots
of code snippets showing them off either in the context of a debugging
exercise or as a proposed solution to a problem, and yet in many cases
their usage seems frivolous in comparison to plain old object-oriented
techniques.
when doing some heavy optimization, I recently found myself writing:

def foobar(arg1, arg2, arg3):
def helper(arg):
do something with arg1 and argument
def foo():
do something with arg1 and arg3 and
call helper
def bar():
do something with arg1 and arg2
def zoo():
do something with arg2 and arg3 and
call helper
# oops; how do I return all these?
class bag(object):
pass
bag = bag()
bag.foo = foo
bag.bar = bar
bag.zoo = zoo
return bag

which, I think, deserves no further comment...

</F>

Dec 6 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.