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
To sum up:
Arguments on Status Quo:
+ Andreas Waldenburger: it works and there just is no need to change
it
+ need no change
+ Andreas Waldenburger: Getting the Python comunity to replace self
with something shorter will never compensate for the time you spent
bullying it through
- Confusion for number of parameters
- The standard 'self' is too long
- Newbie FAQ
- It is ugly
Arguments on "def self.method(" as "def method(self" inside a class:
+ OP: It reduces confusion for number of parameters
+ Patrick Mullen: The symetry of "def self.func(blah)==def func
(self,blah)" and "ob.func(blah)==func(ob.blah)" is kind of neat.
+ OP: Backward compatible
+ OP: It is explicit
- Marc 'Blackjack' Rintsch: they [newcomers] will run into *both*
variants in tutorials, code, and books, so it might be even more
confusing.
- Carl Banks: def <something>(): == <somthing> = <the defined
function>, but def self.method(): return 1 != self.method = lambda: 1
- `self` in this context might be misconstrued as the class object and
thus `def self.foo` might be misunderstood ... as a defining a
classmethod rather than an instance method.
- It is ugly
? Syntax sugar or replacement? Many people prefers this to be
replacement to reduce confusion.
Arguments on variants of $
+ Russ P.: looks like S(elf)
+ Russ P.: more succinct with no loss of readability
- Antoine de Groote: slightly less readable.
- Antoine de Groote: wouldn't require this new syntax (def meth($,
args): $.foo)
- Andreas Waldenburger: "self" is a speaking identifier, "$" isn't
- Obscure symbol
- It is ugly
Unresolved:
? Patrick Mullen: Outside a class definition?
I think we have to test this on newbies. Personally, I think the new
syntax would confuse newbies too, though not as much as the tricky
error message we currently have (code: foo.bar(1, 2, 3, 4); Error:
TypeError: foo() takes exactly 4 arguments (5 given); Newbie: "what
the... 1.. 2.. 3.. 4.., I correctly gave 4 arguments, python counted
the wrong number of arguments").
If this dead horse is revived because of that reason, then I'd go with
changing the error message to something that is less confusing to
newbies[1]. I remember being tripped with the (thinking that python
miscounted the number of argument) when I was new. This has the
advantage of backward compatibility and no syntax change, just less
misleading error message.
[1] anything could work, but I like this one: (c is an instance of
class C)
if the code is: c.foo(...), Error: "TypeError: c.foo() takes exactly 3
argument"
while if the code is: C.foo(...), Error: "C.foo() takes exactly 4
arguments"
You can implement c.foo as a curried C.foo function, catch C.foo's
TypeError exception then reraise it as c.foo exception.
