>> 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? >> > What's the advantage? If there is not a good reason, I would strongly > opposed polluting the language.
Did you read the blog post? The advantage is having a less confusing situation for newbies (confusing the number of arguments to a method call). > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
