On Jul 27, 3:54 pm, Steven D'Aprano <[EMAIL PROTECTED] 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 <[EMAIL PROTECTED] > > 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. -- http://mail.python.org/mailman/listinfo/python-list