Guido's new method definition idea
Carl Banks
pavlovevidence at gmail.com
Sat Dec 6 16:33:22 EST 2008
On Dec 5, 8:21 pm, "Daniel Fetchinson" <fetchin... at googlemail.com>
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
More information about the Python-list
mailing list