On Dec 5, 8:21 pm, "Daniel Fetchinson" <[EMAIL PROTECTED]> wrote: > Hi folks, > > The story of the explicit self in method definitions has been > discussed to death and we all know it will stay. However, Guido > himself acknowledged that an alternative syntax makes perfect sense > and having both (old and new) in a future version of python is a > possibility since it maintains backward compatibility. The alternative > syntax will be syntactic sugar for the old one. This blog post of his > is what I'm talking about: > > http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay... > > The proposal is to allow this: > > class C: > def self.method( arg ): > self.value = arg > return self.value > > instead of this: > > class C: > def method( self, arg ): > self.value = arg > return self.value
-1 I explained why deep in the thread but I'll elaborate more here. When I see a def statement, I mentally equate that to an assigment to the thing being def'ed. So for instance, when I see this: def <something>(): I think of it like this: <somthing> = <the defined function> Thus, if I were to see a function definition like this def foo.bar(): return 1 I would think you were defining a function and assigning it to foo.bar. IOW, it would be mostly equivalent to this: foo.bar = lambda: 1 (Analogously, I would expect a definition like this: def baz[10](): return 1 to be equivalent to this: baz[10] = lambda: 1 ) So, if, inside a class definition, I were to see this: def self.method(): return 1 Well, I'd understand that is was a method assigment, of course, but it would conflict with what I would expect the natural meaning of something like def a.b() would be. The above statement is not equivalent to: self.method = lambda: 1 but I think that's what it ought to be, in general. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
