understanding self

David Fraser davidf at sjsoft.com
Fri Jul 9 11:48:26 CEST 2004

Roy Smith wrote:
> In article <ccirf5$51j$1 at ctb-nnrp2.saix.net>,
>  David Fraser <davidf at sjsoft.com> wrote:
>>For example, there could be a keyword 'method' which defines a method 
>>object that takes self as its first parameter even though it's not 
>>declared. So the two __cmp__ definitions below would be equivalent:
>>class Complex:
>>     # ...
>>     def cmpabs(self, other):
>>         return self.abs().__cmp__(other.abs())
>>     method cmpabs2(other):
>>         return self.abs().__cmp__(other.abs())
> Yes, you are right, you could design things to work that way.  But why 
> would you want to?  Having two ways to do the same thing just adds 
> complexity without adding my value.
> People learning the language have to learn two different things.  Some 
> people will adopt one style, and some will adopt the other.  As a 
> result, we would have two different bodies of code floating around.  
> You'd end up with things like this:
> 1) Pythonista A has adopted the "explicit self" style, and convinces his 
> friend to learn the language.  He teaches the "explicit self" style to 
> his friend.
> 2) The friend is happy with the new language and goes out into the world 
> confident that he's added a new and useful skill to his portfolio.
> 3) The friend picks up a piece of code written by pythonista B, who has 
> adopted the "implicit self" style, and discovers that he can't make 
> heads or tails of it.
> 4) The friend changes his mind about Python, saying, "Gee, if I wanted a 
> language in which there's more than one way to do it, I would have stuck 
> with Perl".
> 5) The Python world has lost another potential convert, ultimately 
> hastening the end of all intelligent life as we know it.

Actually since method binding is happening anyway the programmer always 
has to be aware of it. So I don't think the stylistic change is hard to 


More information about the Python-list mailing list