Guido's new method definition idea

[John Roth]

On Dec 5, 7: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
>
> 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
>
> --
> Psss, psss, put it down! -http://www.cafepress.com/putitdown

Sigh. If you make --both-- self and cls keywords, then 90% of the
problems that Guido mentions in the blogspot post just vanish because
whether it's an instance method, a class method or a static method can
be inferred from the method body.

In particular, the decorator problem goes away (the decorators are
irrelevant, and can be ignored) and so does the problem with injecting
a method into an object.

It is, of course, harder to implement, and it would not be backwards
compatible because all the internal wrappers vanish as well. That
makes problems for anyone who is looking through __dict__ to find
particular kinds of method.

John Roth