[Tutor] why "self" in methods? (fwd)

[Marilyn Davis]

I realize that I only sent this to Gonçalo:

-- 

---------- Forwarded message ----------
Date: Mon, 5 Apr 2004 16:20:40 -0700 (PDT)
From: Marilyn Davis <marilyn at deliberate.com>
To: Gonçalo Rodrigues <op73418 at mail.telepac.pt>
Subject: Re: [Tutor] why "self" in methods?

On Mon, 5 Apr 2004, Gonçalo Rodrigues wrote:

> Em Mon, 5 Apr 2004 18:12:21 +0100, "Alan Gauld"
> <alan.gauld at blueyonder.co.uk> atirou este peixe aos pinguins:
> 
> >> Also, about the self controversy, think about nested definitions
> >> of classes. You get into trouble with the implicit self thingy.
> >
> >Really? How so? Surely that's merely a matter of scoping.
> >I agree that self being explicit is "a good thing" but
> >it is not necessary, other languages seem to manage quite
> >well without it.
> >
> 
> [Answering also to Marylin Davis]
> 
> Suppose that self was a keyword naming the implicit object that's
> passed to methods. Consider the following example:
> 
> class Outer(object):
>     def amethod(arg):
>         class Inner(object):
>             def amethod(arg):
>                 self.arg = arg #What's self here?
>         return inner()
> 
> Is self from the inner or from the outer? The "logical" answer would
> be from the inner amethod from the Inner class. But then the outer
> self is shadowed -- not good. And since it's implicit... you know

I think that attributes of Outer are not visible from Inner anyway?
Do I have that right?

> where I'm getting at.

No.  I don't.

> 
> Explicit is better than implicit. And although from the top of my head
> I can't remember a use case of unbound methods, *I have used them*
> several times. Suppose there were no unbound methods, what should be
> 
> class Outer(object):
>     def amethod(arg):
>          ....
> 
> Outer.amethod
> 
> If methods are attributes of the class object, then the above must
> return something sensible. And if it is to remain callable, well, it
> must receive the instance explicitely as a parameter. Perhaps you
> could write some wrappers, etc. that would do this for you, but
> somehow I think that without the explicit self it would not be very
> elegant. Besides, it gives a very handy syntax for calling a super
> class method that is overriden.
> 
> Also in class methods, in meta methods, etc. the explicit self allows
> me to call the self, cls, that is
> 
> 
> class Outer(object):
>     def method(cls):
>         ....
>     method = classmethod(method)
> 
> which IMHO is much better from a raedability point of view
> 
> Read the FAQ entry on this for a couple more reasons.
> 
> So, my verdict is definitely: explicit self is a *very good* Python
> feature and a clear mark of excellent design. And to the stake with
> the blasphemers that dare oppose the BDFL :-)

Gulp.

I googled for what GvR says:

6.9. Q. Why must 'self' be declared and used explicitly in method
definitions and calls?

A. By asking this question you reveal your C++ background. :-)
When I added classes, this was (again) the simplest way of
implementing methods without too many changes to the interpreter. I
borrowed the idea from Modula-3. It turns out to be very useful, for
a variety of reasons.

First, it makes it more obvious that you are using a method or
instance attribute instead of a local variable. Reading "self.x" or
"self.meth()" makes it absolutely clear that an instance variable or
method is used even if you don't know the class definition by heart.
In C++, you can sort of tell by the lack of a local variable
declaration (assuming globals are rare or reasily recognizable) -- but
in Python, there are no local variable declarations, so you'd have to
look up the class definition to be sure.

Second, it means that no special syntax is necessary if you want to
explicitly reference or call the method from a particular class. In
C++, if you want to use a method from base class that is overridden in
a derived class, you have to use the :: operator -- in Python you can
write baseclass.methodname(self, <argument list>). This is
particularly useful for __init__() methods, and in general in cases
where a derived class method wants to extend the base class method of
the same name and thus has to call the base class method somehow.

Lastly, for instance variables, it solves a syntactic problem with
assignment: since local variables in Python are (by definition!) those
variables to which a value assigned in a function body (and that
aren't explicitly declared global), there has to be some way to tell
the interpreter that an assignment was meant to assign to an instance
variable instead of to a local variable, and it should preferably be
syntactic (for efficiency reasons). C++ does this through
declarations, but Python doesn't have declarations and it would be a
pity having to introduce them just for this purpose. Using the
explicit "self.var" solves this nicely. Similarly, for using instance
variables, having to write "self.var" means that references to
unqualified names inside a method don't have to search the instance's
directories.



-- 






> 
> With my best regards,
> G. Rodrigues
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 

--