Re: [Tutor] garbage collection/class question
On 12.01.2013 02:19, Mitya Sirenef wrote: Functions are the same, (called methods), but the self object is different for each instance, and represents the instance. Consider that since the logic performed by the method is the same (if it wasn't, you'd define it as a separate method, right?), there would be no reason to make a separate method for each instance. As you know from working with functions, the same function may create different output if its arguments are different (from another call), but if the arguments are the same, it will create the same output (I'm ignoring things like random module). Well, that's why the first argument for a method is 'self', which is different for each instance. So to rephrase what you and also other wrote: By setting oakTree = Tree() I create a new Tree() class instance. Now calls to oakTree.grow() access functions of the Tree class, by traversing to it's Superclass Tree. The self then, which also is used in the Superclass Function only tells, work with the own (self) values of the class instance, instead of the values of the class itself. I guess that's right. The core idea of having a class and one or more instances is very versatile and powerful, all of the other concepts are much less needed especially as you're starting out. For example, you can have a class tree and methods and a bunch of tree instances; a classmethod would allow you to perform an action without making an instance first, but it's not like it's hard to make an instance -- it's just that in some cases it's clearer and more straightforward to use a classmethod, like Alan pointed out, but if you happen to forget about classmethods, you could easily get by without them. The same applies to Borg pattern, etc. Actually Im puzzled with the difference between a classmethod and a regular function definition inside a class object. Does the classmethod just mean that I can use the class math and call math.random() without creating an instance of math before using random() ? To what you write, it would make sense like that. Of course the math module has to be imported first. But thats not the point now I guess :) So I assume the functions are shared across thus one decleration has been made in Tree class and all siblings are using that one? They are usually called methods if they belong to a class, and yes they're shared. Okay, that makes sense - that class functions/methods (confusing with that decorator to talk about) are accessible and shared across all class instances - and its also what I noticed by using some code like following and the id() function. Dave was asking what code I meant to get the memory address on where a function is lurking: - class market(): def __init__(self): self.name = 'Market' def getMarketPrice(self): print self print self.__dict__ myInstancesList = [] for x in range(0, 10): myInstancesList.append( market() ) print id(myInstancesList[x].getMarketPrice) print myInstancesList - Which outputs the same memory reference for the function getMarketPrice of all instances of the market class plus the instances inside a list myInstancesList. I dont use a dictionary which might be confusing, but makes more sense to work with. Also id() mentioned here: http://stackoverflow.com/questions/121396/accessing-object-memory-address And thank you all for the explanations. :) Jan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 12/01/13 08:09, Jan Riechers wrote: So to rephrase what you and also other wrote: By setting oakTree = Tree() I create a new Tree() class instance. Now calls to oakTree.grow() access functions of the Tree class, by traversing to it's Superclass Tree. No, they traverse to its Tree class. Superclasses are only involved when you use inheritance. Consider: class Tree: def __init__(self,height=0): self.height = height def getHeight(self): return self.height def EverGreen(Tree):# subclass of Tree def __init__(self, height=0, color='green'): Tree.__init__(self,height) self.color = color def getColor(self): return self.color t = Tree() print t.getHeight() # calls Tree.getHeight g = EverGreen() print g.getHeight()# calls Tree.getHeight by searching superclass print g.getColor() # calls EverGreen.getColor So the superclass is only used in the case of g.getHeight() Python looks for getHeight in the class of EverGreen and can't find it. So it looks in the superclass Tree to see if it can find getHeight there. The self then, which also is used in the Superclass Function only tells, work with the own (self) values of the class instance, instead of the values of the class itself. I guess that's right. Maybe, I'm not sure what you mean. self is a reference to the instance invoking the method. Actually Im puzzled with the difference between a classmethod and a regular function definition inside a class object. All methods are functions defined inside classes. regular functions are by definition NOT defined in a class. regular functions require no lookup mechanism and do not have a magic first parameter like self. Does the classmethod just mean that I can use the class math and call math.random() without creating an instance of math before using random() ? Maybe, if math were a class. But math is actually a module which is different to a class. Okay, that makes sense - that class functions/methods (confusing with that decorator to talk about) The decorator is only used for classmethods not for instance methods. Most of the time you don't need to use classmethods you only need instance methods. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 12.01.2013 11:24, Alan Gauld wrote: On 12/01/13 08:09, Jan Riechers wrote: So to rephrase what you and also other wrote: By setting oakTree = Tree() I create a new Tree() class instance. Now calls to oakTree.grow() access functions of the Tree class, by traversing to it's Superclass Tree. No, they traverse to its Tree class. Superclasses are only involved when you use inheritance. Consider: class Tree: def __init__(self,height=0): self.height = height def getHeight(self): return self.height def EverGreen(Tree):# subclass of Tree def __init__(self, height=0, color='green'): Tree.__init__(self,height) self.color = color def getColor(self): return self.color t = Tree() print t.getHeight() # calls Tree.getHeight g = EverGreen() print g.getHeight()# calls Tree.getHeight by searching superclass print g.getColor() # calls EverGreen.getColor So the superclass is only used in the case of g.getHeight() Python looks for getHeight in the class of EverGreen and can't find it. So it looks in the superclass Tree to see if it can find getHeight there. Actually I miss the terminology but that was what I thought to describe - also referring to your initial post on my question. If a class is based on a super class, the message lookup traversal goes from child to superclass, which now makes sense. The self then, which also is used in the Superclass Function only tells, work with the own (self) values of the class instance, instead of the values of the class itself. I guess that's right. Maybe, I'm not sure what you mean. self is a reference to the instance invoking the method. Given: class Market(): def __init__(self): self.traders = 0 def addTrader(self): self.traders += 1 instanceMarket = market() print instanceMarket.traders # 0 instanceMarket.addTrader() print instanceMarket.traders # 1 So the value of traders is unique to the instance, but the class function addTrader, refers to the instance on which the function is invoked on (using self), but is declared only once for all instances based on market. That also does now make sense. :) Actually Im puzzled with the difference between a classmethod and a regular function definition inside a class object. All methods are functions defined inside classes. regular functions are by definition NOT defined in a class. regular functions require no lookup mechanism and do not have a magic first parameter like self. Does the classmethod just mean that I can use the class math and call math.random() without creating an instance of math before using random() ? Maybe, if math were a class. But math is actually a module which is different to a class. I think again the terms are mixing things up. I tried that with the classmethod decorator and ended up with something like this: class market(): __balance = 500 @classmethod def getBalance(cls): print cls.__balance In this case now, from what was explained and what meant to say, market.getBalance() can now called without creating an instance of that class (like a module, even so it is not.) So calling: market.getBalance() # -- 500 Okay, that makes sense - that class functions/methods (confusing with that decorator to talk about) The decorator is only used for classmethods not for instance methods. Most of the time you don't need to use classmethods you only need instance methods. Sorry again for the long post and mixing up the wordings, I guess I have to practice and read a bit more, but I understand now more of the OOP concept and inner workings than before - so it helped already :) Jan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 10.01.2013 19:50, Mitya Sirenef wrote: On 01/10/2013 09:06 AM, richard kappler wrote: class Tree(object): height = 0 def grow(self): self.height += 1 You may have a dozen of related functions and you can logically group them together by making them methods of a class, making it easier to think about and work on the logic of your program. Actually one question about those dozens of related instances generated by: greenwoodTree = Tree() oakTree = Tree() Both, greenwoodTree and oakTree, are derived from Tree class, thus receiving the features and also - if so - holding unique values created in there __init__ generator method - self.height, self.color and so forth uniquely each. But do both share the same function memory space from the class Tree? I am currently trying also to get my head wrapped around OOP in general, but not 100% sure so that derived instances use the same functions (also memory wise speaking) - or are there several definitions of grow ? The confusion came somehow when reading about classmethods and staticmethods and patterns like Singleton, monostate, borg... from which I understand only ensure that the self.height properties are shared across multiple instances of a given class? From what I tried out using id() and generating functions in a loop - the id(class.function) provided the same result when printed out, according to that: http://stackoverflow.com/questions/121396/accessing-object-memory-address So I assume the functions are shared across thus one decleration has been made in Tree class and all siblings are using that one? Thank you in advance for clarification. Jan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 01/11/2013 02:41 PM, Jan Riechers wrote: On 10.01.2013 19:50, Mitya Sirenef wrote: On 01/10/2013 09:06 AM, richard kappler wrote: class Tree(object): height = 0 def grow(self): self.height += 1 You may have a dozen of related functions and you can logically group them together by making them methods of a class, making it easier to think about and work on the logic of your program. Actually one question about those dozens of related instances generated by: greenwoodTree = Tree() oakTree = Tree() Both, greenwoodTree and oakTree, are derived from Tree class, It's important that we use correct, or at least close terminology. A derived class is VERY different from an instance. greenWoodTree and oakTree are bound to different instances of Tree. thus receiving the features and also - if so - holding unique values created in there __init__ generator method __init__ is not a generator. it's simply a method. A method is a function that's defined inside a class - self.height, self.color and so forth uniquely each. We have to be careful here. Such data can be attributes of an instance, or they can be attributes of a class. Strangely enough, this example has a self.height and tree.height that are both called height, but technically distinct values. I think it's best if you avoid such things, and use unique names till you've got the fundamentals straight. But do both share the same function memory space from the class Tree? I wouldn't use the term function memory space, but I'll say this much. Unless you do something tricky, there is only one method Tree.grow, and all instances share that same method. No duplicated memory at all. I am currently trying also to get my head wrapped around OOP in general, but not 100% sure so that derived instances use the same functions (also memory wise speaking) - or are there several definitions of grow ? Not yet. Creating instances don't duplicate any methods. You'd have to do something explicit, and advanced. The confusion came somehow when reading about classmethods and staticmethods and patterns like Singleton, monostate, borg... from which I understand only ensure that the self.height properties are shared across multiple instances of a given class? I'd consider all of those as advanced techniques, and a complete confusion at your present stage. classmethods and staticmethods affect the parameters that a method gets, not whether data properties belong to the class or to the method. From what I tried out using id() and generating functions in a loop - the id(class.function) provided the same result when printed out, according to that: http://stackoverflow.com/questions/121396/accessing-object-memory-address So I assume the functions are shared across thus one decleration has been made in Tree class and all siblings are using that one? Without showing the code in this loop, I can't comment on what you observed. Don't have any idea what you mean by a sibling. The only meaning I can think of is that two classes each derived from a common base class can be considered siblings. But you don't do any deriving in this email. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 11/01/13 19:41, Jan Riechers wrote: class Tree(object): height = 0 def grow(self): self.height += 1 Actually one question about those dozens of related instances generated by: greenwoodTree = Tree() oakTree = Tree() Both, greenwoodTree and oakTree, are derived from Tree class, Ok, a small terminology issue. They are not derived from Tree, they are Trees. They are two instances of the same class. Derived is used to suggest that they are sub classes of Tree via inheritance, a whole different discussion. receiving the features and also - if so - holding unique values created in there __init__ generator method - self.height, self.color and so forth uniquely each. But do both share the same function memory space from the class Tree? Yes. each instance holds a reference to its class. The class holds the function definitions. That's why you need a self parameter, it tells the class method definition which instance is being operated upon. I am currently trying also to get my head wrapped around OOP in general, but not 100% sure so that derived instances use the same functions (also memory wise speaking) - or are there several definitions of grow ? instances all refer to their class which holds the methods for the class. Where inheritance is concerned the class then holds a further reference to its parent class and Python looks for the earliest method definition as it traverses that class hierarchy. In other words if the object class doesn't have a method definition to match the message name then it looks in the superclass's definition for such a method, and if not there it looks in the superclass's superclass and so on until it finds a match. It is this search that makes methods different to simple functions. The confusion came somehow when reading about classmethods and staticmethods and patterns like Singleton, monostate, borg... from which I understand only ensure that the self.height properties are shared across multiple instances of a given class? Not quite. Class attributes are common across *all* instances of the class. Class methods are, like instance methods, stored in the class but do not need an instance to exist to call them. In fact class methods can be used as factories to create instances. This is a common pattern where you want a way to recover stored classes from a database or file or over a network connection. For example: foo = MYClass() # create a brand new instance in memory id = foo.store(DB) # save it in database del(foo) # get rid of the object in memory foo2 =- MYClass.restore(db, id)# new instance loaded from DB. bar = MYClass.load(someSocket) #instance read from network port store() is an instance method that stores the instance data in a database. restore() is a class method that resurrects that instance by loading it from the database load() is a class method that reads the data on a network port and interprets it as instance data and returns a new instance with those values.. From what I tried out using id() and generating functions in a loop - the id(class.function) provided the same result when printed out, Yes, because they are shared. But note that this is all implementation detail, there are other OOP languages that do things differently. Python's approach is the most common but not guaranteed. In fact I'm not even sure if it's guaranteed across different Python implementations! -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 01/11/2013 02:41 PM, Jan Riechers wrote: On 10.01.2013 19:50, Mitya Sirenef wrote: On 01/10/2013 09:06 AM, richard kappler wrote: class Tree(object): height = 0 def grow(self): self.height += 1 You may have a dozen of related functions and you can logically group them together by making them methods of a class, making it easier to think about and work on the logic of your program. Actually one question about those dozens of related instances generated by: greenwoodTree = Tree() oakTree = Tree() I just want to clarify, I meant you may have dozens of related functions and then move them all into a single class (i.e. I wasn't talking about instances, although you can of course have dozens of instances, too). So, let's say, you have: def f1(): .. def f2(): .. def f3(): .. And it occurs to you, since they're all related, it's good to have them all in the same class: class F(object): def f1(self): .. def f2(self): .. def f3(self): .. There are already really good answers so I'll just add a few notes below... Both, greenwoodTree and oakTree, are derived from Tree class, thus receiving the features and also - if so - holding unique values created in there __init__ generator method - self.height, self.color and so forth uniquely each. But do both share the same function memory space from the class Tree? I am currently trying also to get my head wrapped around OOP in general, but not 100% sure so that derived instances use the same functions (also memory wise speaking) - or are there several definitions of grow ? Functions are the same, (called methods), but the self object is different for each instance, and represents the instance. Consider that since the logic performed by the method is the same (if it wasn't, you'd define it as a separate method, right?), there would be no reason to make a separate method for each instance. As you know from working with functions, the same function may create different output if its arguments are different (from another call), but if the arguments are the same, it will create the same output (I'm ignoring things like random module). Well, that's why the first argument for a method is 'self', which is different for each instance. The confusion came somehow when reading about classmethods and staticmethods and patterns like Singleton, monostate, borg... from which I understand only ensure that the self.height properties are shared across multiple instances of a given class? The core idea of having a class and one or more instances is very versatile and powerful, all of the other concepts are much less needed especially as you're starting out. For example, you can have a class tree and methods and a bunch of tree instances; a classmethod would allow you to perform an action without making an instance first, but it's not like it's hard to make an instance -- it's just that in some cases it's clearer and more straightforward to use a classmethod, like Alan pointed out, but if you happen to forget about classmethods, you could easily get by without them. The same applies to Borg pattern, etc. Learn to be comfortable with classes and instances and you'll be able to make a wide range of programs. From what I tried out using id() and generating functions in a loop - the id(class.function) provided the same result when printed out, according to that: http://stackoverflow.com/questions/121396/accessing-object-memory-address So I assume the functions are shared across thus one decleration has been made in Tree class and all siblings are using that one? They are usually called methods if they belong to a class, and yes they're shared. HTH, - mitya -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 01/11/2013 04:32 PM, Dave Angel wrote: On 01/11/2013 02:41 PM, Jan Riechers wrote: On 10.01.2013 19:50, Mitya Sirenef wrote: On 01/10/2013 09:06 AM, richard kappler wrote: class Tree(object): height = 0 def grow(self): self.height += 1 You may have a dozen of related functions and you can logically group them together by making them methods of a class, making it easier to think about and work on the logic of your program. Actually one question about those dozens of related instances generated by: greenwoodTree = Tree() oakTree = Tree() Both, greenwoodTree and oakTree, are derived from Tree class, It's important that we use correct, or at least close terminology. A derived class is VERY different from an instance. greenWoodTree and oakTree are bound to different instances of Tree. thus receiving the features and also - if so - holding unique values created in there __init__ generator method __init__ is not a generator. it's simply a method. A method is a function that's defined inside a class - self.height, self.color and so forth uniquely each. We have to be careful here. Such data can be attributes of an instance, or they can be attributes of a class. Strangely enough, this example has a self.height and tree.height that are both called height, but technically distinct values. I think it's best if you avoid such things, and use unique names till you've got the fundamentals straight. But do both share the same function memory space from the class Tree? I wouldn't use the term function memory space, but I'll say this much. Unless you do something tricky, there is only one method Tree.grow, and all instances share that same method. No duplicated memory at all. I am currently trying also to get my head wrapped around OOP in general, but not 100% sure so that derived instances use the same functions (also memory wise speaking) - or are there several definitions of grow ? Not yet. Creating instances don't duplicate any methods. You'd have to do something explicit, and advanced. The confusion came somehow when reading about classmethods and staticmethods and patterns like Singleton, monostate, borg... from which I understand only ensure that the self.height properties are shared across multiple instances of a given class? I'd consider all of those as advanced techniques, and a complete confusion at your present stage. classmethods and staticmethods affect the parameters that a method gets, not whether data properties belong to the class or to the method. From what I tried out using id() and generating functions in a loop - the id(class.function) provided the same result when printed out, according to that: http://stackoverflow.com/questions/121396/accessing-object-memory-address So I assume the functions are shared across thus one decleration has been made in Tree class and all siblings are using that one? Without showing the code in this loop, I can't comment on what you observed. Don't have any idea what you mean by a sibling. The only meaning I can think of is that two classes each derived from a common base class can be considered siblings. But you don't do any deriving in this email. I think it's very intuitive (at least, it was to me when I was learning), to view it as a common starting point for all instances. In this example it makes sense that all trees (or a general idea of a tree) starts with a 0 height, and then each particular tree ends up with a different height after a while. -m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On Thu, Jan 10, 2013 at 3:06 PM, richard kappler richkapp...@gmail.comwrote: Class is still something I struggle with. I think I'm finally starting to get my head wrapped around it, but the discussion in a different thread has sparked a question. First, please check my understanding: A class creates objects, it's like a template that allows me to create as many copies as I want of the object but allows me to have slightly different versions of the object by having different values for the variables within the object, which I can set with arguments? By using __init__ (self) I instantiate a new copy of the object? This is essentially correct. There are some intricacies in python with __init__, which doesn't create a new object but merely initiates it. Python also has __new__, which actually creates a new instance. But this is mostly just details, in 99% of cases we can simply write an __init__ method for initialization and not worry about __new__ Whether the above is correct or not (and do please correct me/ tutor me), my question is, if I create objects in a while True loop, do the objects get garbage collected, ie. disappear when the loop returns to the beginning and creates new versions of the objects? Psuedo code example: (presuming I have a class that creates a lemon, a lime and has a function that operates on them called juice) while True: lemon = yellow() # create a yellow object called lemon lime = green() # create a green object called lime drink = juice(lemon, lime) # operate on objects lemon and lime in a function called juice resident in the class So, using the above example, when the loop reaches the end and returns to the beginning, new lemons and limes are created, yes? What happens to the old ones? Or have I still got this completed boggled? In a general sense, objects are garbage collected when there are no more references to these objects, i.e. when you become unable to use them. On each pass of the loop, you make the names lemon, lime and drink point to new instances. The instances they were pointing to previously thus become inaccessible. If there are no other references to these objects in the program, they will be garbage collected (whether this happens immediately or after a while differs depending on python implementation). Hugo ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 01/10/2013 09:06 AM, richard kappler wrote: Since you don't specify Python version or implementation, I'll use CPython version 2.7 for the details below. Jython (for java environments) and other implementations are likely to differ in their garbage collection details. But the effect will be the same. I'm also assuming new-style classes, which are all that's available in Python 3, but in 2.7, you get one by making sure your class is derived from object. Class is still something I struggle with. I think I'm finally starting to get my head wrapped around it, but the discussion in a different thread has sparked a question. First, please check my understanding: A class creates objects, it's like a template that allows me to create as many copies as I want of the object but allows me to have slightly different versions of the object by having different values for the variables within the object, which I can set with arguments? Python is already full of class objects. The only special thing about 'class' is it lets you define your own types of objects. There are dozens of built-in and library types, and you're probably already familiar with many of them. For example, every integer is an instance of the int class. Python has a special syntax that lets you create them invisibly, but they are there, nonetheless. I don't think it's useful to think of them as copies of a master int, but rather as independent int objects, each with some content that may or may not be unique. By using __init__ (self) I instantiate a new copy of the object? The new INSTANCE is made when somebody invokes MyClass(arg1). During that creation, two methods of MyClass are called. The __new__() method actually creates the empty class object, and associates methods and such to it. And then the __init__() method gets control and can add other attributes to it. Most programs let the default __new__() method do its thing. Whether the above is correct or not (and do please correct me/ tutor me), my question is, if I create objects in a while True loop, do the objects get garbage collected, ie. disappear when the loop returns to the beginning and creates new versions of the objects? Psuedo code example: (presuming I have a class that creates a lemon, a lime and has a function that operates on them called juice) But your code below does not fit the sentence above. while True: lemon = yellow() # create a yellow object called lemon Actually, the object has no name. The name lemon is bound to the object in that line, but it's really a one-way binding. However, CPython keeps a count of such bindings for each object, called a reference count. lime = green() # create a green object called lime drink = juice(lemon, lime) # operate on objects lemon and lime in a function called juice resident in the class Since you don't give any context, I don't know where() juice is defined, or where this loop is defined, nor what you mean by 'the class'. But if you mean what you say, then you're missing an object parameter to the juice method. So, using the above example, when the loop reaches the end and returns to the beginning, new lemons and limes are created, yes? Not exactly. New instances of class yellow and class green are created, and the names lemon and lime are unbound from the old objects, and bound to those new objects. If this loop is all the code, then the old objects now have zero reference counts and will be immediately freed. Technically this is different than garbage collection, but the effect is the same. What happens to the old ones? Or have I still got this completed boggled? regards, RIchard Objects that have no bindings are inaccessible, and eventually go away (get freed). -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] garbage collection/class question
On 01/10/2013 09:06 AM, richard kappler wrote: Class is still something I struggle with. I think I'm finally starting to get my head wrapped around it, but the discussion in a different thread has sparked a question. First, please check my understanding: A class creates objects, it's like a template that allows me to create as many copies as I want of the object but allows me to have slightly different versions of the object by having different values for the variables within the object, which I can set with arguments? There are good answers already, I just want to address this question; you are correct but classes allow you to do other things, too. You may want to use a class even if you don't need multiple instances. Classes allow you to group related functionality and data together: class Tree(object): height = 0 def grow(self): self.height += 1 You may have a dozen of related functions and you can logically group them together by making them methods of a class, making it easier to think about and work on the logic of your program. Classes also create a namespace for each instance: x = 1 class A(object): x = 2 a = A() a.x = 3 Here, a.x is completely independent of the global namespace's 'x'. In instance methods, it can be called with 'self.x' . There are other things classes provide, but these are the most important in small / medium size programs. You can read up on OOP here: http://en.wikipedia.org/wiki/Object-oriented_programming HTH, - m -- Lark's Tongue Guide to Python: http://lightbird.net/larks/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
