Attack a sacred Python Cow

[Russ P.]

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.
It's a red herring that you seem to be using to obscure the fact that
you have no rational argument to make.

By the way, according to your "reasoning," Python 2.5 was *not* Python
when 2.1 was the latest version. But now it is! Yes, Python has
actually changed, yet remained Python. What a concept!

> 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.

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.

> > 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.

Actually, you do. The name "self" could be used for any argument -- or
even for a local variable. No good programmer would do such a thing,
of course, but not all programmers are good programmers (and not all
Python programmers read the stern admonitions against such practices
on this forum). And if you are reviewing critical code, you had darn
well better verify that "self" is the first argument. With my
proposal, you would not need to do that.

Is that a major advantage? No. But it is a minor advantage. And it is
perfectly logical.

Am I suggesting that unnamed first arguments should always be used?
No, of course not. But I am saying that in some cases it can unclutter
and simplify the code.

> 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.

Bzzzzt. Wrong again. The exact same convention could apply there. And
the same benefits apply: less clutter and no need to keep the name of
the first argument in your head when reading the code.

> > 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.

Actually, I think it's elegant. And I'll bet that if Guido had
suggested it, you would think it was beautiful. Why force a name to be
used when none is needed? Think about lambda functions.