list/classmethod problems

[ahart]

I'm pretty new to python and am trying to write a fairly small
application to learn more about the language. I'm noticing some
unexpected behavior in using lists in some classes to hold child
objects. Here is some abbreviated code to help me explain.

############### ############### ######
class Item(object)
__text = ""
def __get_text(self ):
return self.__text
def __set_text(self , value):
self.__text = value
text = property(fget=_ _get_text, fset=__set_text )

def __init__(self, text=""):
self.__text = text

#...some other methods here...

class Parent(object):
__items = []
def __get_items(sel f):
return self.__items
items = property(fget=_ _get_items)

def addItem(self, item):
"""Adds an Item object to the internal list."""
self.__items.ap pend(item)

def __init__(self, items=[]):
if(len(items)>0 ):
for item in items:
self.addItem(it em)

def __str__(self):
s = "<parent>"
for item in self.__items:
s += "<item>%s</item>" % item.text
s += "</parent>"

#...some other methods here...

if(__name__=="_ _main__"):
i1 = Item("one")
i2 = Item("two")
i3 = Item("three")

p1 = Parent([i1, i2])
p2 = Parent([i3])

print str(p1)
############### ############### ######

When I run this script, I expect to see the following string printed:

"<parent><item> one</item><item>two</item></parent>"

Instead, I see the following:


"<parent><item> one</item><item>two</item><item>thre e</item></parent>"

Apparently, the p1 instance somehow thinks that the i3 instance is in
its list. The i3 instance should instead be in the list for p2. By the
way, when I call the __str__() method of p2, I get the same results as
when I do it for p1. The list appears to be acting as if it were a
static member - which it is not.

I do have some @classmethod methods in these classes in my complete
script. Would that confuse the interpreter into thinking that other
members are also static?

I can't seem to find any information on this problem. Does anyone have
any ideas?

Thank you.

[Diez B. Roggisch]

Re: list/classmethod problems

>[color=blue]
> Apparently, the p1 instance somehow thinks that the i3 instance is in
> its list. The i3 instance should instead be in the list for p2. By the
> way, when I call the __str__() method of p2, I get the same results as
> when I do it for p1. The list appears to be acting as if it were a
> static member - which it is not.
>
> I do have some @classmethod methods in these classes in my complete
> script. Would that confuse the interpreter into thinking that other
> members are also static?
>
> I can't seem to find any information on this problem. Does anyone have
> any ideas?[/color]

Read this:

http://www.python.org/doc/faq/general/#why-are-default-values-shared-between-objects

HTH,
Diez

[Scott David Daniels]

Re: list/classmethod problems

ahart wrote:[color=blue]
> I'm pretty new to python and am trying to write a fairly small
> application to learn more about the language. I'm noticing some
> unexpected behavior in using lists in some classes to hold child
> objects. Here is some abbreviated code to help me explain.
>
> When I run this script, I expect to see the following string printed:
>
> "<parent><item> one</item><item>two</item></parent>"
>
> Instead, I see the following:
>
>
> "<parent><item> one</item><item>two</item><item>thre e</item></parent>"
>
> Apparently, the p1 instance somehow thinks that the i3 instance is in
> its list. The i3 instance should instead be in the list for p2. By the
> way, when I call the __str__() method of p2, I get the same results as
> when I do it for p1. The list appears to be acting as if it were a
> static member - which it is not.
>
> I do have some @classmethod methods in these classes in my complete
> script. Would that confuse the interpreter into thinking that other
> members are also static?
>
> I can't seem to find any information on this problem. Does anyone have
> any ideas?[/color]

First, a few kvetches:

(1) Submit the _actual_code_ when you have problems, not paraphrases:[color=blue]
> class Item(object)[/color]
should have been (and probably was):
class Item(object):
[color=blue]
> def __str__(self):
> ...
> s += "</parent>"[/color]
should have been (and probably was):
def __str__(self):
...
s += "</parent>"
return s

(2) You must have been a Java or C++ programmer. Don't be so stingy
with access to your variables and methods (all the __xxx methods
and variables). Just use a single underscore (at least for the
methods) telling users, "don't muck with this." The double
underscores make figuring out what's going interactively awkward.

(3) The if statement takes a boolean expression, not parens around a
boolean expression. "if a > b:" is the way to write a test, not
"if(a>b):" (which is why I think Java or C++).

And now to your actual question:
[color=blue]
> ############### ############### ######
> class Item(object)
> __text = ""[/color]

The line above is unnecessary (and deceptive). It sets a _class_
variable named _Item__text to a zero-length string.
[color=blue]
> def __get_text(self ):
> return self.__text
> def __set_text(self , value):
> self.__text = value
> text = property(fget=_ _get_text, fset=__set_text )
>
> def __init__(self, text=""):
> self.__text = text[/color]
This line sets an _instance_ variable named _Item__text to the arg.[color=blue]
>
> #...some other methods here...
>
> class Parent(object):
> __items = [][/color]
The line above is unnecessary (and deceptive). You want
a list-per instance, but you are accessing the class variable below
[color=blue]
> def __get_items(sel f):
> return self.__items
> items = property(fget=_ _get_items)
>
> def addItem(self, item):
> """Adds an Item object to the internal list."""
> self.__items.ap pend(item)
>
> def __init__(self, items=[]):
> if(len(items)>0 ):
> for item in items:
> self.addItem(it em)[/color]

If you wrote this method as either:
def __init__(self, items=[]):
self.__items = []
for item in items:
self.addItem(it em)
or:
def __init__(self, items=[]):
self.__items = list(items)

You would have the effect you want -- a list per instance.
By the way,[color=blue]
> if(len(items)>0 ):
> for item in items:
> self.addItem(it em)[/color]
Two complaints about this:
First, the "Pythonic way to test for a non-zero length list is "if var"
Second, even if the test were:[color=blue]
> if items:
> for item in items:
> self.addItem(it em)[/color]
That code is just plain slower (and less clear) than:
for item in items:
self.addItem(it em)
If items is zero length, it goes through the loop body zero times.[color=blue]
>
> def __str__(self):
> s = "<parent>"
> for item in self.__items:
> s += "<item>%s</item>" % item.text
> s += "</parent>"
>
> #...some other methods here...
>
> if(__name__=="_ _main__"):
> i1 = Item("one")
> i2 = Item("two")
> i3 = Item("three")
>
> p1 = Parent([i1, i2])
> p2 = Parent([i3])
>
> print str(p1)
> ############### ############### ######
>[/color]
Now you get the output you expect.

By-the-by, why shouldn't the first class be simply?:

class Item(object)
def __init__(self, text=""):
self.text = text

Finally, defining __repr__ rather than __str__ will make it
easier to fiddle with your code interactively w/o keeping anything
from working.

--Scott David Daniels
scott.daniels@a cm.org

[Bruno Desthuilliers]

Re: list/classmethod problems

ahart a écrit :[color=blue]
> I'm pretty new to python and am trying to write a fairly small
> application to learn more about the language. I'm noticing some
> unexpected behavior in using lists in some classes to hold child
> objects. Here is some abbreviated code to help me explain.
>
> ############### ############### ######
> class Item(object)
> __text = ""
> def __get_text(self ):
> return self.__text
> def __set_text(self , value):
> self.__text = value
> text = property(fget=_ _get_text, fset=__set_text )[/color]


If you don't have any computation to do in the getter/setter, just use
direct attribute access. If the need arise, then it will be time to use
a property.

Also, takes care with leading double underscores, they may not do what
you think. The usual convention is to use a single leading underscore
for implementation details.

(snip)
[color=blue]
> class Parent(object):
> __items = [][/color]

This is a class attribute. It will be shared by all instances.

(snip)
[color=blue]
> The list appears to be acting as if it were a
> static member - which it is not.[/color]

Well, in Python it's called a class attribute, but that's pretty much
the same thing.
[color=blue]
> I do have some @classmethod methods in these classes in my complete
> script. Would that confuse the interpreter into thinking that other
> members are also static?[/color]

Don't you think such a bug would have been spotted a long time ago ?-)

If you come from Java, take the time to read this:

http://dirtsimple.org/2004/12/python-is-not-java.html

HTH

[ahart]

Re: list/classmethod problems

Diez, Scott, and Bruno,

I thank you all for your help and suggestions. I wasn't aware that
default values were considered class (static) values. That seems a
little odd to me, but as long as I know that's the case, I'll be fine.

I initialized my list member in the __init__() method and all is
working as it should now.

Again, I thank you all.

[bruno at modulix]

Re: list/classmethod problems

ahart wrote:[color=blue]
> Diez, Scott, and Bruno,
>
> I thank you all for your help and suggestions. I wasn't aware that
> default values were considered class (static) values.[/color]

These are *not* 'default values'. Defining a name in the body of a class
statement bind that name to the *class*. To bind a name to the instance,
you have to do it inside an instance method - usually in the __init__()
method. Understand that there's not way to bind anything to an instance
before you actually *have* an instance !-)
[color=blue]
> That seems a
> little odd to me,[/color]

Yes, it's very different from languages like Java or C++, but it makes
perfect sens once you understand Python's object model.

(snip)
[color=blue]
> Again, I thank you all.
>[/color]
You're welcome.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Magnus Lycka]

Re: list/classmethod problems

ahart wrote:[color=blue]
> I thank you all for your help and suggestions. I wasn't aware that
> default values were considered class (static) values. That seems a
> little odd to me, but as long as I know that's the case, I'll be fine.[/color]

It's all very simple and regular: Things in the class scope
is shared between all instances of the class. This applies to
both __text, __get_text, __set_text, text and __init__ in the
Item class. All these things are shared, since they are defined
in the scope of the class. That's the namespace where they
exists, not the instance. The typical thing to put in the class
scope is obviously methods, although some plain data can belong
there too.

When you access something in the instance, e.g. self.__text,
where self is an Item instance, it will follow a certain lookup
procedure. If it finds __text in the instance, it will use that
object. If not, it will look in the scope of the class, and if
it's not found there, it will look in base classes of Item and
so on.

This means that __get_text will find Item.__text if __text does
not exist in the instance object. On the other hand, when you
assign to self.__text in __set_text, you will get a new name
__text in the instance, and the next __get_item call will find
a __text in the instance, not the shared in the class scope.

Assignments in Python means "make this name refer to that object".
As far as I understand, that's like Java if you don't use those
half-life types like int that aren't proper objects. So, it does
never mean "copy a value to this location in memory" as it does
in C / C++.

With the list in Parent, you never make any assignment, so
there will never be any __item in the instance namespace. All
self.__items lookups will end up in the class namespace.

Since lists are mutable, you can change this list object, and
the changes will be visible to all instance. With the __text
attribute in Item, which is a string (immutable) there is no
way to change the value. To get a new __text value in the
class scope, you'd have to do self.__class__. __text = ... or
Item.__text = ..., and I doubt that you would do that by
accident! ;^)

What made you try to put your private attributes in the class
scope instead of putting them in __init__? Perhaps it's hard
to entirely give up the idea of somehow declaring your class
attributes even if there is no such things as variable
declarations in Python. :)