Guido's new method definition idea

Ken Seehart ken at seehart.com
Mon Dec 15 03:38:57 EST 2008


-*ε*

Admittedly a tough call. I see the attraction of the proposed syntax.

Maybe somewhat more readable since the declaration syntax matches the 
usage syntax, which is nice. I think it would have been superior to the 
current syntax if it had been done that way in the first place. However, 
since newbies will still have to learn both syntaxes in order to read 
other peoples code, it does not simplify the language.

The main thing I don't like about it is that it violates this principle: 
"There should be one-- and preferably only one --obvious way to do it."

Ken

Daniel Fetchinson 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.html
>
> 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
>
> I.e. explicit self stays only the syntax is slightly different and may
> seem attractive to some. As pointed out by Guido classmethods would
> work similarly:
>
> class C:
>     @classmethod
>     def cls.method( arg ):
>         cls.val = arg
>         return cls.val
>
> The fact that Guido says,
>
> "Now, I'm not saying that I like this better than the status quo. But
> I like it a lot better than [...] but it has the great advantage that
> it is backward compatible, and can be evolved into a PEP with a
> reference implementation without too much effort."
>
> shows that the proposal is viable.
>
> I'd like this new way of defining methods, what do you guys think?
> Anyone ready for writing a PEP?
>
> Cheers,
> Daniel
>
>   




More information about the Python-list mailing list