By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,400 Members | 903 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,400 IT Pros & Developers. It's quick & easy.

Strange Behavior

P: n/a
class Foo:
def __init__(self, name, data=[]):
self.name = name
self.data = data

def addData(self, val):
self.data.append(val)
f = Foo('a')
f.addData(1)
f.addData(2)

f2 = Foo('b')

print f.name, f.data
print f2.name, f2.data

----------------------------
OUTPUT
---------------------------
a [1, 2]
b [1, 2]
.....why would f and f2 contain the same data??

however, if I do this instead....

f = Foo('a')
f.addData(1)
f.addData(2)

f2 = Foo('b', [])

print f.name, f.data
print f2.name, f2.data

----------------------------
OUTPUT
---------------------------
a [1, 2]
b []
Any ideas? is this a bug?

Oct 16 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
abcd wrote in news:11**********************@i3g2000cwc.googlegro ups.com in
comp.lang.python:
class Foo:
def __init__(self, name, data=[]):
http://docs.python.org/ref/function.html#l2h-619

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Oct 16 '06 #2

P: n/a
Rob Williscroft wrote:
http://docs.python.org/ref/function.html#l2h-619

thanks. weird that it works that way since they even state "This is
generally not what was intended."

oh well.

Oct 16 '06 #3

P: n/a
On Mon, 16 Oct 2006 07:26:05 -0700, abcd wrote:
class Foo:
def __init__(self, name, data=[]):
The binding of the name "data" to the empty list happens at compile time,
not runtime.
self.name = name
self.data = data

def addData(self, val):
self.data.append(val)
Every time you call addData on an instance, it appends to the same list.
So all instances created with Foo(name) share the same list in data.

Think of it like this:

some_list = []
x = Foo("fred", some_list)
y = Foo("wilma", some_list)

Isn't it obvious now that both instances share the same list? That x.data
and y.data don't just have the same value, but are the same object? The
same thing happens when you set the default.

f = Foo('a')
f.addData(1)
f.addData(2)

f2 = Foo('b', [])
And in this case, you've passed a DIFFERENT empty list as an argument.
The normal Python way for handling this situation is to not use mutable
objects as defaults unless you want this behaviour. Instead, use None as
the default value:

class Foo:
def __init__(self, name, data=None):
self.name = name
if data is None: self.data = []
else: self.data = data

Any ideas? is this a bug?
Well, it's a bug in your code :)

It isn't a bug in Python. At worst, it is a "gotcha", but it is a
deliberate design decision, and quite useful. For example, this is good
for caching complicated calculations:

def function(x, _cache={}):
# _cache is initialised to an empty dictionary at compile time
if _cache.has_key(x):
return _cache[x]
else:
# complicated and time consuming calculation happens
_cache[x] = result
return result


--
Steven.

Oct 16 '06 #4

P: n/a
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
It isn't a bug in Python. At worst, it is a "gotcha", but it is a
deliberate design decision, and quite useful. For example, this is good
for caching complicated calculations:

def function(x, _cache={}):
# _cache is initialised to an empty dictionary at compile time
if _cache.has_key(x):
return _cache[x]
The above can be done explicitly:

def function(x):
if function._cache.has_key(x):
return function._cache[x]
...
# function gets an initially-empty cache
function._cache = {}

So the existing behavior, while not a bug (since it's documented), may
well be a wart.
Oct 16 '06 #5

P: n/a
On 2006-10-16, Steven D'Aprano
<st***@REMOVE.THIS.cybersource.com.auwrote:
Well, it's a bug in your code :)

It isn't a bug in Python. At worst, it is a "gotcha", but it is
a deliberate design decision, and quite useful. For example,
this is good for caching complicated calculations:
I'd say the feature is "usable" rather than "useful", like
bitfields in C.

--
Neil Cerutti
Next Sunday Mrs. Vinson will be soloist for the morning service.
The pastor will then speak on "It's a Terrible Experience."
--Church Bulletin Blooper
Oct 16 '06 #6

P: n/a
Steven D'Aprano wrote:
It isn't a bug in Python. At worst, it is a "gotcha", but it is a
deliberate design decision, and quite useful. For example, this is good
for caching complicated calculations:
it's also used to pass in *objects* instead of names into an inner scope.

</F>

Oct 16 '06 #7

P: n/a
abcd wrote:
Rob Williscroft wrote:
>http://docs.python.org/ref/function.html#l2h-619


thanks. weird that it works that way since they even state "This is
generally not what was intended."
The "not intended" refers to the programmer making the mistake of creating a
shared instance - which usually isn't intended, as you yourself are an
example of.

Diez
Oct 16 '06 #8

P: n/a
On Mon, 2006-10-16 at 10:51, Steven D'Aprano wrote:
On Mon, 16 Oct 2006 07:26:05 -0700, abcd wrote:
class Foo:
def __init__(self, name, data=[]):

The binding of the name "data" to the empty list happens at compile time,
not runtime.
I think this statement needs to be clarified. The binding of "data" to
the empty list *does* happen at runtime, not at compile time. However,
the binding happens only once, when the "def" statement is executed, as
opposed to every time the __init__ function is called.

-Carsten
Oct 16 '06 #9

P: n/a
Carsten Haese wrote:
I think this statement needs to be clarified. The binding of "data" to
the empty list *does* happen at runtime, not at compile time. However,
the binding happens only once, when the "def" statement is executed, as
opposed to every time the __init__ function is called.
to be precise, it happens every time the "def" statement is executed.

</F>

Oct 16 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.