understanding self

[Roy Smith]

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.