[EMAIL PROTECTED] wrote: > Having read previous discussions on python-dev I think I'm not the only > Python programmer who doesn't particularly like python's "self" > parameter: > > class Foo: > def bar(self, a,b): > return a+b > Foo().bar(1,2) => 3 > > The main reason (at least for me) is that there's simply too much > "magic" in it. Why does the expression left of the '.' get promoted to > the first parameter? It even goes further: > > Foo.bar(Foo(), 1,2) > > works, but: > > Foo.bar(1,2,3) > > doesn't, just because of the "magical first parameter" in a member > function. But: > > Foo.__dict["bar"]__(1,2,3) > > Does work. > > The point is, I _do_ think it's a good idea to explicitly write > "self.SomeMember" for member-access, so I thought: why can't we be > equally explicit about member function declaration? Wouldn't it be nice > if I could write (say, in Python 3k, or maybe later): > > class Foo: > def self.bar(a,b): > return a+b > Foo().bar(1,2) => 3
That's similar to ruby. Really this isn't going to change in python, at least not anytime soon. If it really bothers you, then ruby is something to look into. But I think most people who don't like the extraneous 'self' in python just consider it a minor inconvenience and don't even notice it after using python for a while. It is only when you switch between python and other languages that you notice it again. If python extends decorators to allow them to be applied to classes as well as functions (which is more likely to happen perhaps), then you'll see a bunch of useful hacks pop up to eliminate the need for 'self' in method declarations. -- http://mail.python.org/mailman/listinfo/python-list
