Attack a sacred Python Cow

[Steven D'Aprano]

On Sun, 27 Jul 2008 12:33:16 -0700, Russ P. wrote:

> On Jul 27, 1:19 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Sat, 26 Jul 2008 17:14:46 -0700, Russ P. wrote:
> 
>> > 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.
> 
> And what does that have to do with my suggestion? Absolutely nothing.

Not at all. You're suggesting a change to Python's syntax. I've suggested 
a couple more changes to Python syntax. I don't intend them to be taken 
seriously, but only to illustrate a point that syntax defines how a 
language is written. You want to change that.


> It's a red herring that you seem to be using to obscure the fact that
> you have no rational argument to make.

I don't have to make a rational argument for keeping the status quo. That 
status quo just *is*. You want people to change, you need to convince 
them that such a change is not just "not bad" but a serious advantage, 
enough to make up for all the work required to implement it.

I'm listening. Tell me why removing self if not merely harmless, but 
actively better.

[...]


>> By "better" do you mean "uglier"? If so, I agree with you. If not, then
>> I disagree that it is better.
> 
> You seem to be freaked out by an empty argument. Actually, it bothers me
> a bit too, which is why I suggested that a period could be used as the
> first argument to indicate that, like Clint Eastwood in The Good, the
> Bad, and the Ugly, "self" had no name here.

Well there you go now. How should we *talk* about this piece of code? Try 
writing a comment or docstring, or even sitting down with a fellow 
programmer and discussing it. What do you call this implicit Object With 
No Name?

def fun( , cat):
    .cat = cat  # assumes that the Object With No Name has foo

versus

def fun(self, cat):
    self.cat = cat  # assumes that self has foo

Before you suggest that people will continue to call the first argument 
"self" but just not write it down anywhere, I suggest that's a terrible 
idea and one which will confuse a lot of people. "Where's this 'self' 
defined? I can't find it anywhere!"

A slightly better suggestion is "the instance", but that fails here:

class C(object):
    def method(, other):
        assert isinstance(other, C)
        .cat = other  # assumes that the instance has foo
        # er, that is to say, the implicit instance, 
        # not the other instance


The ability to talk easily about the code is invaluable. Implicit self 
makes it harder to talk about the code.


[...]

>> Even uglier than the first. Convince me there's a benefit.
> 
> Actually, I think it's elegant. And I'll bet that if Guido had suggested
> it, you would think it was beautiful.

Oh please. I think the syntax for ternary if is ugly, and Guido came up 
with that, and it doesn't even use punctuation.

> Why force a name to be used when none is needed?

But a name is needed. 

class Foo(base1, base2, base3):
    def meth(self, arg):
        super(Foo, self).meth(arg)
        print self
        try:
            value = _cache[self]
        except KeyError:
            value = some_long_calculation(self)
        

How do you pass self to arbitrary functions without a name?



-- 
Steven