use of "self", was "No Do while/repeat until looping construct in python?"

[William Sonna]

On Fri, 14 Mar 2003 13:20:53 -0500, Chermside, Michael wrote:

>> On the other hand, if you have a valid reason why "self" is
>> advantageous FROM THE USER's POINT OF VIEW I would like to hear it.
> 
> I'm not sure I really believe you (about desiring to hear a reason why
> "self" is advantageous), but I'll give it a shot anyhow.
> 
> Consider the following Java snippet (sorry, I don't know Ruby well
> enough to get the syntax right).
> 
>     public class MyClass extends ParentClass {
>         String accessId;
>         public MyClass(accessId) {
>             this.accessId = accessId;
>         }
>         public int overlyLongFunction() {
>             // Here goes 162 lines of messy code
>             return (jiggerPercent > 100) ? 100 : jiggerPercent;
>         }
>         }
>         }
> In the last line of overlyLongFunction, we refer to the variable
> "jiggerPercent". This could be either a local variable OR an instance
> variabler... and there's no way to tell which one it is. Notice how the
> constructor uses a common java idiom which makes use of this ambiguity.
> 
> 
Yes, the constuctor is clear as can be.  The rules in Java are also clear
as can be, and evey bit as clear as the self in Python - local variables
or function parameters overshadow instance variables of the same name. But
I am not troubled at all by the enhanced clarity that self provides.

What I am sick of is getting nailed by the interpreter for forgetting to
add "self" to every lousy instance variable name - or even worse - having
it treat my omission as a local variable.  The mandatory self is itself a
source of errors, and I believe based on my own experience that it creates
more errors than it prevents.

Call it a feature if you will, but my guess is that its an implementation
requirement that has a side benefit for those who like mandatory
qualification.

> In Python, it would refer to either "jiggerPercent" or to
> "self.jiggerPercent", and the reader would be immediately aware of which
> was intended. (Note that Python values terseness for the sake of the
> READER of the code, not because the WRITER of the code has lazy
> fingers.)
> 
> Of course, Python isn't perfect in this regard... it still has three
> different namespaces (local, global, built-in) where the variable might
> live, but at least it distinguishes the instance-variable namespace.
> 
> 
The biggest problem I have personally found with name pollution is
tracking hand-me-down names from base classes I know nothing about.

Unfortunately, while "self" helps a tiny bit, it doesn't really solve THAT
problem.

> You can argue over whether you LIKE this feature, but it IS a
> commonly-mentioned advantage of the use of self. Now you said that
> "common sense says the instance variables are local", but I believe this
> is a very odd use of the term of "common sense", given that instance
> variables are _NOT_ the same as local variables... not in Python, in
> Java, or in Ruby. Doesn't mean you have to like typing "self", but it IS
> one good reason (among others) for requiring it.
>
>
Instance variables are accessed identically to local variables within
mehtods in virtually every other major programming language in use today.
Wouldn't you call that common?

The case of a name overload is usually deemed a *special* case, and as you
pointed out in your example, the syntax of Java to resolve it couldn't be
clearer.

But enough with my sour grapes.

Truth is, Python 2.2 is a MAJOR step in the direction of making Python
into a full object-oriented language.  Its the best Python yet, and
hopefully 2.3 will be even better.

And I will continue to hope "self" at someday cease to be
mandatory.

In the mean time, I'll keep makng the same dumb mistake over, and over,
and over, and over, and over, and over, and over, .....