Daniel Fetchinson a écrit :
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
Once again: how is adding "magical" syntax going to reduce confusion ?
(confusing the number of arguments to a method
call).
This is only confusing the first time. The correct solution to this
problem is IMHO to better document Python's object model, specially how
the descriptor protocol turns functions into methods.
--
http://mail.python.org/mailman/listinfo/python-list
