[Tutor] garbage collection/class question

Mitya Sirenef msirenef at lightbird.net
Sat Jan 12 01:19:21 CET 2013


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/



More information about the Tutor mailing list