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

class members vs instance members

P: n/a
Ive spent a few days going thru a couple of Python tutorials. No
problem until I got to classes. I guess my java mindset is blocking my
vision. I've borrowed another thread's code snippet and cannot explain
the results:
class MyClass:
list = []
myvar = 10

def add(self, x):
self.list.append(x)
self.myvar = x

def printer(self):
print self.list
print self.myvar

a = MyClass()
b = MyClass()

for n in range(20):
a.add(n)

print "list in a:"
a.printer()
print "list in b:"
b.printer()

This produces:
list in a:
list in a:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
19
list in b:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
10

WHY do the "class members" list and myvar seem to behave differently?
Given the way that list[] is supposedly shared why doesnt myvar exhibit
the same behavior? It seems that myvar is acting like a true "instance
member". Is this simply because of the underlying types?
TIA

Jul 9 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
hdixon a écrit :
Ive spent a few days going thru a couple of Python tutorials. No
problem until I got to classes. I guess my java mindset is blocking my
vision.
Then http://dirtsimple.org/2004/12/python-is-not-java.html
I've borrowed another thread's code snippet and cannot explain
the results:
class MyClass:
class MyClass(object):
list = []
This may not be too harmful in the given context, nut shadowing builtin
types may not be a good idea.
myvar = 10

def add(self, x):
self.list.append(x)
"list" is a class attribute. It's shared by all instances of MyClass.
This is a FAQ AFAICT.
self.myvar = x
This creates an instance attribute named myvar that shadows the class
attribute of the same name

(snip expected results)
WHY do the "class members" list and myvar seem to behave differently?
cf above. And notice that in Python, binding (aka 'assignement') and
name lookup on objects are different beasts. There have been quite a few
threads about this recently.
Given the way that list[] is supposedly shared why doesnt myvar exhibit
the same behavior?
Because binding to self.myvar creates the instance attribute "myvar".
Notice that you have not rebound "list".
It seems that myvar is acting like a true "instance
member".
It is one.
Is this simply because of the underlying types?
Nope, it's because in the first case (MyClass.list, accessed as
self.list) you just call methods on the list object, which has no effect
on the binding.
Jul 9 '06 #2

P: n/a

Bruno Desthuilliers wrote:
hdixon a écrit :
Ive spent a few days going thru a couple of Python tutorials. No
problem until I got to classes. I guess my java mindset is blocking my
vision.

Then http://dirtsimple.org/2004/12/python-is-not-java.html
I've borrowed another thread's code snippet and cannot explain
the results:
class MyClass:

class MyClass(object):
list = []

This may not be too harmful in the given context, nut shadowing builtin
types may not be a good idea.
myvar = 10

def add(self, x):
self.list.append(x)

"list" is a class attribute. It's shared by all instances of MyClass.
This is a FAQ AFAICT.
self.myvar = x

This creates an instance attribute named myvar that shadows the class
attribute of the same name

(snip expected results)
WHY do the "class members" list and myvar seem to behave differently?

cf above. And notice that in Python, binding (aka 'assignement') and
name lookup on objects are different beasts. There have been quite a few
threads about this recently.
Given the way that list[] is supposedly shared why doesnt myvar exhibit
the same behavior?

Because binding to self.myvar creates the instance attribute "myvar".
Notice that you have not rebound "list".
It seems that myvar is acting like a true "instance
member".

It is one.
Is this simply because of the underlying types?

Nope, it's because in the first case (MyClass.list, accessed as
self.list) you just call methods on the list object, which has no effect
on the binding.
ok - i "think" its beginning to dawn on me. BTW - the blog above was a
good read for me. I _am_ trying to bring java into the mix and its
screwing me up big time. I'll go back over the chapters that dicuss
binding/name lookups.
Thanks

Jul 9 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.