Why self?

[Charles Hixson]

Alex Martelli wrote:
> Robb Shecter wrote:
> 
> 
>>Brian Quinlan wrote:
>>
>>>...  Actually, private instance
>>>variables are uncommon in general.
>>
>>Sounds like a difference in design philosophies.  In my code, private
>>everything is the norm, with a very thin/small public API.
...
> Alex
> 

If you are subclassing a class that someone else has written, you don't 
want to accidentally redefine an internal name.  Sorry.  I can accept 
that you should be able to explicitly access it, but to be able to 
change it by accident is (would be?) a misfeature.

I didn't believe that this happened in Python.  It does, and it seems a 
significant flaw.  My understanding is that if you define a variable in 
a class that subclasses another class, then unless you take definite 
steps to cause things to happen otherwise, you are defining a new 
variable that is local to the scope of the class that you are currently 
defining, and will not impact routines that you call from parental 
classes.  Experiment shows that this isn't what happens.
from __future__ import nested_scopes
does not fix this problem, as I assumed that it would.

Let's be explict:
from __future__ import nested_scopes
class A:
    def ma(self):
        print  "ma, ma"
    def pa(self):
        self.ma()
class B(A):
    def ma():
        print "hello, world"
tst = B()
tst.pa()

Testing this produces the message, "hello, world"
This seems to be the wrong message.  The version of pa that was called 
was the version defined in class A, so the routine called should have 
been the routine defined in class A.

Or, to me more accurate, for libraries to have maximal portability, I 
would want the message to have generated "ma, ma", and I had been 
assuming that nested_scopes would result in that being the message that 
was produced.
-- 
-- Charles Hixson
Gnu software that is free,
The best is yet to be.