Why the 'self' argument?

Jonathan Aquino Jon_Aquino at shaw.ca
Sun Sep 7 08:03:56 CEST 2003


(Paul Foley replied to my e-mail directly. Below are his remarks,
which I was interested to read. At the end is my reply.)


 >> 1) I abhor redundancy. My first impression on seeing self as the
first
 >> parameter of all method declarations is that it seems redundant --
it
 >> probably isn't technically, but it looks redundant: (self, (self,
 >> (self, (self, ...

 PF> Of course it's not redundant -- no more than the "x" is redundant
in

 PF>   def ln(x):
 PF>       ...

 PF>   def sin(x):
 PF>       ...

 PF>   def cos(x):
 PF>       ...

 PF>   def tan(x):
 PF>       ...

 PF>   def cosh(x):
 PF>       ...

 PF>   def sinh(x):
 PF>       ...

 PF> etc., etc.  Gee, look: (x, (x, (x, (x, (x, ...

 >> 2) The number of parameters in the method call is one less than
the
 >> number of parameters in the method declaration.

 PF> No it isn't.  The first argument is just in a strange place:

 PF>     x.foo(y,z)
 PF>     ^     ^ ^
 PF>     1     2 3

 PF> x.foo is really just weird syntax for curry(foo, x); i.e.,

 PF>    q = x.foo

 PF> is essentially

 PF>    q = lambda *a: foo(x, *a)

 PF> (but in a different namespace), so

 PF>    x.foo(y,z)   is   q(y,z)   is   (lambda *a: foo(x, *a))(y,z)

 PF> and there are exactly as many args in the call as in the
definition
 PF> (as, of course, there must be!)


 PF> Of course, it would be infinitely better to write foo(x,y,z),
opening
 PF> the way to _real_ OO (with multiple dispatch), but x.foo(y,z) is
what
 PF> Python supports...


I was interested to read your response. 
I think you and I are looking through different lenses. Perhaps
influenced by my Java/Smalltalk background, I'm simply uncomfortable
when I see (1) the first parameter on all method declarations being
the object (didn't have to do this before) and (2) the number of
things
between the parentheses being different for the method declaration and
the method call.

On the other hand, when I read your response it's clear to me that (1)
you are comfortable looking through the lens of functional
programming, so that passing the object in as the first parameter
makes perfect sense to you, and (2) the mismatch in the number of
things
between the parentheses is not a big deal to you (though "strange",
you admit) because as an experienced Python programmer you know what's
going on under the covers.

My opinions are the frank opinions of a Java/Smalltalk programmer
learning Python. And I'm not the only newbie who thinks this seems
strange: the original newbie poster also opined that this is "odd".

Out of the mouths of babes ...




More information about the Python-list mailing list