[Tutor] Self

[Ryan Sheehy]

Thanks Danny & Gregor!

I think I am now beginning to understand. I don't know how to write it down
in words, but yes I think I am beginning to get it.

Thanks heaps,


Ryan




-----Original Message-----
From: Danny Yoo [mailto:dyoo at hkn.eecs.berkeley.edu]
Sent: Friday, 19 December 2003 3:02 AM
To: Ryan Sheehy
Cc: Tutor
Subject: RE: [Tutor] Self




On Thu, 18 Dec 2003, Ryan Sheehy wrote:

> If so, could the call 'Person.pat_head()' still give the same result in
> the play_game method?

Hi Ryan,

This almost works.  However, it's a requirement in Python that the first
parameter in each method has to be 'self'.


(I'm actually lying.  *grin* That last statement was true until Python
2.2.  I'll explain more fully in the bottom of this message.)


Here's one reason for this constraint: if we allow a method that doesn't
take 'self', it would mean that the 'method' doesn't care about its
instance, and in that case, why is it even a method?  *grin*

Methods are really functions that are attached to an object.  These
methods are meant to care about the instance that they're attached to ---
otherwise, it would be more approprate to just write a function.


And in fact, with the original example:

###
class Person:
    def pat_head(self):
        print "I'm patting my head"

    def rub_stomach(self):
        print "I'm rubbing my stomach"

    def play_game(self):
        self.pat_head()
        self.rub_stomach()
###

it makes little sense for Person to be a class with those methods: it
would be so much more simpler to just use functions:

###
def pat_head():
    print "I'm patting my head"

def rub_stomach():
    print "I'm rubbing my stomach"

def play_game():
    pat_head()
    rub_stomach()
###

which is fine.


So the example from before was actually a very bad one in terms of showing
what objects are good for, since none of the methods actually did anything
with 'self'.  Let me augment the original example a bit more more:

###
class Person:
    def __init__(self, name):
        self.name = name
        self.count_heads = 0
        self.count_stomachs = 0

    def summarize(self):
        print "I,", self.name,
        print "have patted my head", self.count_heads, "times",
        print "and rubbed my stomach", self.count_stomachs, "times."

    def pat_head(self):
        print "I,", self.name, "am patting my head"
        self.count_heads += 1

    def rub_stomach(self):
        print "I,", self.name, "am rubbing my stomach"
        self.count_stomachs += 1

    def play_game(self):
        self.pat_head()
        self.rub_stomach()
###

Now these methods use 'self' as a way of sharing and remembering the
status of the object --- we're using 'self' here as a place to store
counts of things.  It should be a little easier to see that passing 'self'
around is useful now.  Most classes will have methods that pay attention
to the state that's stuffed in 'self' --- it's less common to have methods
that totally disregard 'self'.



Going back to your question:

> If so, could the call 'Person.pat_head()' still give the same result in
> the play_game method?


The reason we mentioned this "almost" works is because in newer versions
of Python, it actually is possible to do this, using "static methods".
We can tell the system that, yes, we don't really need 'self' on certain
methods, by marking them with 'staticmethod':


###
class Person:
    def pat_head():
        print "I'm patting my head"
    pat_head = staticmethod(pat_head)


    def rub_stomach():
        print "I'm rubbing my stomach"
    rub_stomach = staticmethod(rub_stomach)


    def play_game():
        Person.pat_head()
        Person.rub_stomach()
    play_game = staticmethod(play_game)
###

And then it works.


The details of this are defined in:

    http://python.org/2.2/descrintro.html#staticmethods


I have to admit: I have this uncomfortable feeling about staticmethod(),
and not just because it's a recent addition to the language.  It just
seems to me that allowing static methods adds little power to the
language, and at the very high cost of complicating explanations like this
one.  *grin*


Anyway, I hope this helps!


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 11/12/2003