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. 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. -- http://mail.python.org/mailman/listinfo/python-list
