Attack a sacred Python Cow

[Steven D'Aprano]

On Sat, 26 Jul 2008 17:14:46 -0700, Russ P. wrote:

> On Jul 26, 2:25 pm, Terry Reedy
>> There is a lot of code you have not seen.  Really.  In informal code I
>> use 's' and 'o' for 'self' and 'other'.  I don't usually post such
>> because it is not considered polite.  So you have seen a biased sample
>> of the universe.
> 
> You take the name down to a single letter. As I suggested in an earlier
> post on this thread, why not take it down to zero letters? 

The question isn't "why not", but "why". The status quo works well as it 
is, even if it isn't perfect. Prove that implicit self is a good idea -- 
or at least prove that it is an idea worth considering.

"I don't like typing self" doesn't convince me. The same argument could 
be made typing parentheses, colons, commas, etc. We could end up with 
something like this:

class Foo base
    def method x y z
        .args = list x y z

        
That's not necessarily wrong, but it's not Python.

It's not enough to show that a change "isn't bad" -- you have to show 
that it is actively good. Why should Python make any changes to the 
current explicit self without a clear and solid reason to change?



> You could if Python accepted something like
> 
> class Whatever:
> 
>     def fun( , cat):
> 
>         .cat = cat
> 
> This is even better than the single-character name, 

By "better" do you mean "uglier"? If so, I agree with you. If not, then I 
disagree that it is better.


> not only because it
> is shorter, but also because there is no question that you are referring
> to "self." No need to look back at the method signature to verify that.

"Don't need to look at the method signature" is not an argument in favour 
of implicit self. You don't need to look at the method signature when 
you're using an explicit self either.

What happens with class-methods? With the cls (or if you prefer klass) 
convention, it is simple to tell what object I am referring to. Now I 
have to go back to the method signature to see if it is a class method or 
instance method, instead of just looking at the explicit name.



> For those who don't like the way the empty first argument looks, maybe
> something like this could be allowed:
> 
>     def fun( ., cat):


Even uglier than the first. Convince me there's a benefit.



-- 
Steven