[Python-3000] Removing 'self' from method definitions

[Ian Bicking]

Josiah Carlson wrote:
> Ian Bicking <ianb at colorstudy.com> wrote:
> 
>>OK, so first Guido says he wants people to speculate less, then he says 
>>he wants them to speculate more.  Who knows.  So, now I speculate more.
>>
>>I propose that the self argument be removed from method definitions.  It 
>>would not be removed from other places, e.g., you'd still use 
>>"self.foo()", but the definition for that method would be "def foo():".
> 
> 
> -1 Why?  Because right now the various methods on a class have obvious
> signature-specific clues as to what they are: instance method (has a
> leading self), class method (has a leading cls or klass generally),
> static method (has no leading self, cls, etc.) .  Removing self (and
> possibly even cls if one goes a step farther) ambiguates what kind of
> method a function definition is, from a signature standpoint.  As was
> said in the decorator discussion; signatures are important and should be
> grepable (that along with readability is why we didn't see decorators
> _inside_ the signature).  By removing the _explicit_ self, we make
> instance methods generally undifferentiatable (is that a word?) from a
> grep standpoint.

Because all kinds of methods live in the same namespace and are *called* 
in the same way, the name alone is sufficient to identify the method. 
That is, searching for "def foo" will find instance, class, and static 
methods, and there can't be both a class and instance method with the 
same name on a class.  "x.foo()" could be an instance, class, or static 
method, so an inclusive search is called for anyway.

Actually reading the method in context, the decorator makes it clear 
what kind of method is being written; @classmethod and the cls argument 
are expressing the same thing.  So outside of grepping it doesn't seem 
that big of an issue.

Ideally introspective tools like pydoc would indicate what kind of 
function you were looking at, as that would be identifiable at runtime.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org