Attack a sacred Python Cow

[Russ P.]

On Jul 27, 3:54 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> 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.

But the syntax change I am suggesting is trivial compared to the
draconian examples you gave.

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

I thought I did just that. I am very meticulous about the appearance
of my code, and the less cluttered the better. That's one of the main
reasons that I use Python. My suggestion would be relatively trivial
to implement, yet it would dramatically reduce clutter. You may not
agree, but I think the case is strong.

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

How do Java and C++ programmers talk about the instance for which the
method was called? I wasn't aware that that was a problem for them.

> 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!"

Any programmer who can't get past that point needs to find a new line
of work -- such as moving furniture.

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

I can only imagine what you must think about lambda functions and list
comprehensions.

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

Off topic, but I happen to like Guido's ternary "if." I use it
wherever I can, within reason.

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

I didn't say you *never* need the name. If you need it, then use it.
But if you don't need it, you shouldn't be forced to use a name just
for the sake of having a name.