"Harlin Seritt" <[EMAIL PROTECTED]> writes:
> I think I know what you mean. When I first started trying to learn the
> OOP aspect of Python I thought it was strange since I had started with
> OOP on Java and C++. Nonetheless, once you get the hang of it, OOP will
> make way more sense than all of the complications of Java and C++ class
> implementations. Let me give you a quick example of what I'm talking
> about:
Um, there are some problems with your commentary.
> class Animal:
> def eats(self):
> print 'The animal eats.'
> def walks(self):
> print 'The animal walks.'
>
> """Here the class Dog instantiates the class Animal. 'Dog' will 'do'
> whatever 'Animal' does plus some other things which we will describe in
> this class code."""
> class Dog(Animal):
> """#the self keyword means that this function will be a class
> function"""
> def communicate(self):
> print 'The dog barks.'
First, the correct terminology is class *method*. Yes, it looks like a
function definition, but it's a class method. Second, "self" isn't a
keyword. It's just a name. You can name any variable self. The first
argument to all class methods is a reference to the instance of the
class that is invoking the method. It can have any name you want, but
by convention in Python is called "self". Consider the following:
py> class C:
... def say(my, message):
... print message
...
py> self = C()
py> self.say("hello")
hello
py>
Finally, *every* def inside a class statement creates a class
method. You don't really need to worry about this, but will see it on
the group. The method can be wrapped, and the defined name rebound to
the wrapper, either via the decorator syntax or directly, using the
classmethod and staticmethod functions.
> """# __init__ function defines what # #will happen as soon as this
> class is instantiated. Also, the overloaded variable designators (color
> = None, fur = None) allow the instantiator to optionally define these
> variables when called from elsewhere."""
>
> def __init__(self, color=None, fur=None):
> """# this time self will designate the variable 'color' # as a
> class variable."""
> self.color = color
> self.fur = fur
These aren't variable designators, and they aern't overloaded. They
are parementers, and they are given default values. This means they
can be omitted from an invocation of the method, in which case the
default values will be used.
> if __name__ == '__main__':
> sparky = Dog(color="White", fur="Short")
> sparky.communicate()
> print sparky.color
> print sparky.fur
> print sparky.eats() # Here sparky will access 'Animal' methods
> that 'Dog' inherited.
> print sparky.walks() # Another method originating from the 'Animal'
> class.
>
> What happens if you don't use 'self' inside your class code? You won't
> be able to access it within the class outside of the method where you
> initialized it. For instance, if you don't designate color with self
> then you can only use the 'color' variable within the __init__()
> method. This is useful whenever you want to use 'color' as a private
> variable.
I'm not sure where to start here.
"self" is a variable name. By convention, it's use is reserved for the
first argument of methods, in which case it is passed the instance
that is invoking the method.
By assigning something to "self.feature", you are assigning a value to
an attribute - "feature" of this instance. This means it'll persist
beyond the function existing.
Assuming you have access to another object - let's call it foo - you
can assign values to it's attributes in the same way, by assigning to
"foo.feature". Once made, such an assignment will persist until it's
either changed, or the object foo ceases to exist.
If you assign to a bare variable name - i.e., one with no dot - it
will by default be local to that function. This means the variable
will cease to exist when the function exits. Some details you should
keep in mind, but can genarlly ignore: When the variable ceases to
exist, the object it reference will lose a reference, which may or may
not cause that object to cease to exist. You can cause an assignment
to refer to a variable in the enclosing modules global name space with
the "global" statement. Finally, if you referene a varaible rather
than assigning to it, it's searched for in the enclosing scopes, out
to the module global namespace.
> The same also goes for methods. Hopefully, you see how useful this can
> be down the road. This way you won't have to use variable/method access
> modifiers like Public, Private, Protected and so forth. If this doesn't
> make sense or you want more clarity, please let me know.
Generally, methods are referred to by referring to a feature of an
instance of an object. The first argument to the method is left off
such an invocation, as the instance the method reference is attached
to will be passed as that parameter. This is the way "self.method"
works - it's a reference to a method of the instance that was used to
invoke the currently executing method. Sometimes, you'll see
invocations of methods from the class, in which case an instance has
to be passed as the first parameter. The only time you're liable to
have to worry about this as you get started is in calling a precursor
to a method, like so:
class A:
def meth(self):
...
class B(A):
def meth(self):
A.meth(self)
...
This is depreciated. You should be using new-style classes and the
super function instead:
class A(object):
def meth(self):
...
class B(A):
def meth(self):
super(B, self).meth()
All features of classes/objects are public. The philosphy is that
"we're all adults here". If you want to indicate that some feature is
an internal implementation detail, and shouldn't be used by client
classes, start it's name with an "_". If you're really desperate, use
a double underscore. Python will mangle "__name" to
"_<classname>__name", making it slightly more painfull to use. This
just makes them hard to use, though, doesn't really hide them. But it
does this for classes that inherit from the class as well as clients
of the class.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
