Why self?

[Robb Shecter]

I think we're actually agreeing about a lot here.

Alex Martelli wrote:

> ...The boundaries of any subsystem should be clean, with emphasis on
> simplicity and clarity of working code rather than architectural
> elaboration...

I like how Python basically gives you access to whatever you want. 
Similar to Smalltalk.  And then Python has ways to flag design 
intentions, which can be either heeded or ignored.  I see "__." like 
this.  I'm not looking to lock out 'junior' programmers, just to make 
the workings of the class clear when used from tools like help() or 
PythonWin IDE.  Without using this flagging system, all variables and 
methods appear to be equally 'public'.

So, back to my original gripe.  I hate having to do 'self.__x' instead 
'x' for an instance variable that:

1. Is part of the implementation, not the interface of a class.
2. Shouldn't be trampled over inadvertently by subclassers.

... and because, it's of course not just self.__x.  It's also self.__b, 
etc. all being used together, combining to some unreadable code.

Again, I'm not looking to 'lock other programmers out', just use 
Python's own tools correctly to flag design intentions or to document 
how code works.


 > I wrote:
>>
>>String name = (String) aVector.element(0)
>>
>>Python doesn't have any problems with implicitness here...
> 
> 
> If you want to force a _string_ representation of aVector's first
> element to be bound to variable name, you'll code:
>         name = str(aVector[0])
> which is roughly on a par with the Java construct

Actually, AFAIK, that is _not_ on par with the Java construct.  That 
ugly Java code isn't changing any kind of representation...  All it is 
doing is allowing you to send a message to the object 'name' that's part 
of the String API.

The message send may still fail "be not understood".  In Java, you'd get 
a class cast exception.  In Smalltalk, you'd get "Message not understood".

Robb