Guido's new method definition idea

[Daniel Fetchinson]

>>> 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.
>
> Similarly, to those coming from Ruby or those operating under the
> frequent misunderstanding that the `def`s are happening in the context
> of a class object (which in reality has yet to be created), `self` in
> this context might be misconstrued as the class object and thus `def
> self.foo` might be misunderstood (through the intuitive equivalence
> you mention) as a defining a classmethod rather than an instance
> method.

This is actually a real counter argument, I think. Self, the instance,
doesn't exist until it is created and certainly doesn't exist during
class creation. So something like

class C:
    def self.meth( arg ):
        return arg

can be confusing since 'self' appears as if it was defined in the
scope of C but clearly it isn't yet.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown