Why the 'self' argument?

[John Roth]

Re: Why the 'self' argument?


"Grant Edwards" <grante@visi.co m> wrote in message
news:3f591d28$0 $175$a1866201@n ewsreader.visi. com...[color=blue]
> In article <vli387c9mm140a @news.supernews .com>, John Roth wrote:
>[color=green][color=darkred]
> >> So that there's no difference between a function and a method.
> >>
> >> Simplicity and orthogonality are good things -- despite what
> >> C++ proponents thing.
> >>
> >> > Hence my comment that requiring it is more complex than not
> >> > requiring it.
> >>
> >> No, it's more complex the Java/Ruby way, since you have to have
> >> two sets of rules for what a name means depending on whether
> >> you're inside a "normal" function or a method. In Python
> >> there's just one set of rules -- mostly.[/color]
> >
> > As I said earlier, it's quite possible to define it so that there
> > is always an instance of some kind; whether that's an instance
> > a class or the module itself.[/color]
>
> I don't follow. You're talking about defining a keyword that
> always refers to the first parameter passed to a function? And
> the declared parameters would refer to the 2nd through Nth
> parameters? What if the keyword isn't used in the function
> definition, then do the delcared parameters refer to the 1st
> through Nth?[/color]

When Python invokes a function, it binds the operands in the
function call to the identifiers named in the function / method
header. If this is a method, it binds the instance (which is not
in the invocation parameter list, btw.) to the first
parameter in the method header.

If you make "self" a reserved word, then all it has to do
is bind the instance to "self," rather than the first identifier
in the parameter list.

In current python, there are two classes of functions (module
level and embedded) and three classes of methods (instance,
class and static.) Instance methods get the current instance,
class methods get the class object as the instance, and the other
three categories get nothing.

As a separate suggestion, I'd have Python bind the module
object to "self" for module functions and static methods. I
haven't figured out what I want done with embedded methods
and unbound methods yet. Notice that this eliminates the
need for the global statement for module functions - all
identifiers are accessible for rebinding through "self."
[color=blue][color=green]
> > I think my comments have shown that you can reduce the amount
> > of scoping / name space rules noticably.[/color]
>
> Compared to what? It sure sounds like you're introducing more
> rules than there are now. How would you propose reducing the
> number of rules?[/color]

If you don't have to write "self" as the first parameter of a method,
that reduces the complexity. Everything else remains the same.

John Roth[color=blue]
>
> --
> Grant Edwards grante Yow! Somewhere in[/color]
Tenafly,[color=blue]
> at New Jersey, a[/color]
chiropractor[color=blue]
> visi.com is viewing "Leave it to
> Beaver"![/color]

[Bengt Richter]

Re: Why the 'self' argument?

On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <newsgroups@jhr othjr.com> wrote:
[...]
[color=blue]
>If you don't have to write "self" as the first parameter of a method,
>that reduces the complexity. Everything else remains the same.
>[/color]
Except for cases where two self-parameters are visible at the same time,
and both are used in an inner scope and must be distinguished by giving
them different names. ISTM you'd have to turn off some dynamic capabilities
of python to make "self" implicit. (An example came up in a past discussion,
some time ago).

Regards,
Bengt Richter

[John Roth]

Re: Why the 'self' argument?


"Bengt Richter" <bokr@oz.net> wrote in message
news:bjbb57$bb2 $0@216.39.172.1 22...[color=blue]
> On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <newsgroups@jhr othjr.com>[/color]
wrote:[color=blue]
> [...]
>[color=green]
> >If you don't have to write "self" as the first parameter of a method,
> >that reduces the complexity. Everything else remains the same.
> >[/color]
> Except for cases where two self-parameters are visible at the same time,
> and both are used in an inner scope and must be distinguished by giving
> them different names. ISTM you'd have to turn off some dynamic[/color]
capabilities[color=blue]
> of python to make "self" implicit. (An example came up in a past[/color]
discussion,[color=blue]
> some time ago).[/color]

You could still give them different names. The proposal is to eliminate
the need to specify "self" in the method header, not in the code in the
method body. That's a different issue, and I don't know of any language
that manages to do it consistently.

John Roth[color=blue]
>
> Regards,
> Bengt Richter[/color]

[Paul Foley]

Re: Why the 'self' argument?

On 05 Sep 2003 15:55:34 GMT, Grant Edwards wrote:
[color=blue]
> In article <vlhba85atlte07 @news.supernews .com>, John Roth wrote:[color=green]
>>
>> "Grant Edwards" <grante@visi.co m> wrote in message
>> news:3f58a2bd$0 $156$a1866201@n ewsreader.visi. com...[color=darkred]
>>> In article <vlh7otscuo8gb1 @news.supernews .com>, John Roth wrote:
>>>
>>> > Technically, it would be possible to make "self" a reserved
>>> > word, and not have to put it in the method declaration.
>>> > However, there are a lot of people who use something other than
>>> > the word "self," so that would break existing code.
>>>
>>> It would also make the language more complex and irregular.[/color]
>>
>> How?[/color][/color]
[color=blue]
> 1) It would add a reserved word.[/color]
[color=blue]
> 2) It would mean that there's some sort of difference between
> a function and a method.[/color]

There *is* a difference between a function and a method (a method
/contains/ a function), unless you just mean that they're both
callable (which is not necessarily true in other languages)

But you can't define methods, you can only define functions (Python
makes methods by "magic"), so the "self" parameter is no different
than any other...it's pretty weird to suggest that it should be
treated differently. Why not treat the 5th parameter specially?

--
Just because we Lisp programmers are better than everyone else is no
excuse for us to be arrogant. -- Erann Gat

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz> "))

[Lukasz Pankowski]

Re: Why the 'self' argument?

Hi,

the answer is in python FAQ:

http://python.org/doc/faq/general.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls

--

=*= Lukasz Pankowski =*=

[Alex Martelli]

Re: Why the 'self' argument?

Grant Edwards wrote:
...[color=blue][color=green]
>> Hence my comment that requiring it is more complex than not
>> requiring it.[/color]
>
> No, it's more complex the Java/Ruby way, since you have to have
> two sets of rules for what a name means depending on whether
> you're inside a "normal" function or a method. In Python
> there's just one set of rules -- mostly.[/color]

Java and Ruby have no "normal functions" -- just methods. Ruby
has what may LOOK like ordinary functions, but they're methods
of the module object...


Alex

[Michael Peuser]

Re: Why the 'self' argument?


"John Roth" <newsgroups@jhr othjr.com>
[color=blue]
> You could still give them different names. The proposal is to eliminate
> the need to specify "self" in the method header, not in the code in the
> method body. That's a different issue, and I don't know of any language
> that manages to do it consistently.[/color]

You'll run into all the problems known from the Pascal with-statement. And
that's not only a readability matter.

Kindly
Michael P

[Isaac To]

Re: Why the 'self' argument?

>>>>> "Michael" == Michael Peuser <mpeuser@web.de > writes:

John> You could still give them different names. The proposal is to
John> eliminate the need to specify "self" in the method header, not in
John> the code in the method body. That's a different issue, and I don't
John> know of any language that manages to do it consistently.

Michael> You'll run into all the problems known from the Pascal
Michael> with-statement. And that's not only a readability matter.

I think John is talking about a syntax that have the self formal argument
implicit, but the self actual argument explicit. Something like this:

class foo:
def __init__(msg):
self.msg = str(msg)
def f(arg):
print self.msg + ', ' + str(arg)
v = foo('hello')
v.f('world') # equivalent to foo.f(v, 'world')

which would be equivalent to the current Python

class foo:
def __init__(self, msg):
self.msg = str(msg)
def f(self, arg):
print self.msg + ', ' + str(arg)
v = foo('hello')
v.f('world') # equivalent to foo.f(v, 'world')

If that's really what he mean, he is correct in every word: the only change
is that you treat self as a reserved word, and the real road-block is that
everybody think that self is not reserved. There is a problem that you can
no longer define normal function in a class, though. The interpretor would
think that the function is a method.

Regards,
Isaac.

[Bengt Richter]

Re: Why the 'self' argument?

On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <newsgroups@jhr othjr.com> wrote:
[color=blue]
>
>"Grant Edwards" <grante@visi.co m> wrote in message
>news:3f591d28$ 0$175$a1866201@ newsreader.visi .com...[color=green]
>> In article <vli387c9mm140a @news.supernews .com>, John Roth wrote:
>>[color=darkred]
>> >> So that there's no difference between a function and a method.
>> >>
>> >> Simplicity and orthogonality are good things -- despite what
>> >> C++ proponents thing.
>> >>
>> >> > Hence my comment that requiring it is more complex than not
>> >> > requiring it.
>> >>
>> >> No, it's more complex the Java/Ruby way, since you have to have
>> >> two sets of rules for what a name means depending on whether
>> >> you're inside a "normal" function or a method. In Python
>> >> there's just one set of rules -- mostly.
>> >
>> > As I said earlier, it's quite possible to define it so that there
>> > is always an instance of some kind; whether that's an instance
>> > a class or the module itself.[/color]
>>
>> I don't follow. You're talking about defining a keyword that
>> always refers to the first parameter passed to a function? And
>> the declared parameters would refer to the 2nd through Nth
>> parameters? What if the keyword isn't used in the function
>> definition, then do the delcared parameters refer to the 1st
>> through Nth?[/color]
>
>When Python invokes a function, it binds the operands in the
>function call to the identifiers named in the function / method
>header. If this is a method, it binds the instance (which is not
>in the invocation parameter list, btw.) to the first
>parameter in the method header.
>
>If you make "self" a reserved word, then all it has to do
>is bind the instance to "self," rather than the first identifier
>in the parameter list.
>
>In current python, there are two classes of functions (module
>level and embedded) and three classes of methods (instance,
>class and static.) Instance methods get the current instance,
>class methods get the class object as the instance, and the other
>three categories get nothing.
>
>As a separate suggestion, I'd have Python bind the module
>object to "self" for module functions and static methods. I
>haven't figured out what I want done with embedded methods
>and unbound methods yet. Notice that this eliminates the
>need for the global statement for module functions - all
>identifiers are accessible for rebinding through "self."
>[color=green][color=darkred]
>> > I think my comments have shown that you can reduce the amount
>> > of scoping / name space rules noticably.[/color]
>>
>> Compared to what? It sure sounds like you're introducing more
>> rules than there are now. How would you propose reducing the
>> number of rules?[/color]
>
>If you don't have to write "self" as the first parameter of a method,
>that reduces the complexity. Everything else remains the same.[/color]

Will this still be possible?
[color=blue][color=green][color=darkred]
>>> def foo(*args): print args[/color][/color][/color]
...[color=blue][color=green][color=darkred]
>>> class A(object): pass[/color][/color][/color]
...[color=blue][color=green][color=darkred]
>>> class B(A): pass[/color][/color][/color]
...[color=blue][color=green][color=darkred]
>>> a = A()
>>> b = B()
>>> A.bar = foo
>>> b.bar('howdy')[/color][/color][/color]
(<__main__.B object at 0x00906E70>, 'howdy')[color=blue][color=green][color=darkred]
>>> a.bar('howdy')[/color][/color][/color]
(<__main__.A object at 0x00907170>, 'howdy')[color=blue][color=green][color=darkred]
>>> foo('howdy')[/color][/color][/color]
('howdy',)
[color=blue][color=green][color=darkred]
>>> A.bar('hello')[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unbound method foo() must be called with A instance as first argument (got str instan
ce instead)[color=blue][color=green][color=darkred]
>>> A.__dict__['bar']('hello')[/color][/color][/color]
('hello',)

I.e., the method-vs-function distinction is a matter of how you access the function dynamically,
not how you define it. There is no static distinction in functionality, AFAIK (though I guess
there could possibly be some speculative optimizations).

(The above doesn't even get into the multiple name issues I alluded to).

Regards,
Bengt Richter

[Jonathan Aquino]

Re: Why the 'self' argument?

Two reasons I cringe when I see self as the first parameter of method
declarations (i.e. "def methodname(self , ...)" (I don't mind self in
the method body)):

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, ...

2) The number of parameters in the method call is one less than the
number of parameters in the method declaration. I'm annoyed when I see
this because I want the rules of the language to be obvious (in this
case, a one-to-one mapping). I would be embarassed to have to explain
this to a beginning programmer.

(I do like how Python indenting indicates blocks, however)

[Harri Pesonen]

Re: Why the 'self' argument?

Jonathan Aquino wrote:[color=blue]
> Two reasons I cringe when I see self as the first parameter of method
> declarations (i.e. "def methodname(self , ...)" (I don't mind self in
> the method body)):
>
> 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, ...
>
> 2) The number of parameters in the method call is one less than the
> number of parameters in the method declaration. I'm annoyed when I see
> this because I want the rules of the language to be obvious (in this
> case, a one-to-one mapping). I would be embarassed to have to explain
> this to a beginning programmer.
>
> (I do like how Python indenting indicates blocks, however)[/color]

I agree, it's not logical. I'm learning Python at the moment, and like
it very much. This "self" thing seems to be the only odd feature, it
feels like the whole class feature was added later. The Quick Python
book says that Python was designed to be object oriented from the ground
up. Is it true?

Harri

[Grant Edwards]

Re: Why the 'self' argument?

In article <Ucp6b.3992$ZB4 .3874@reader1.n ews.jippii.net> , Harri Pesonen wrote:
[color=blue]
> I agree, it's not logical. I'm learning Python at the moment, and like
> it very much. This "self" thing seems to be the only odd feature,[/color]

It seemed quite natural to me, but perhaps that's because I'd
used other languages that worked the same way. Coming from
Modula-3 and Smalltalk, the way classes worked in Python seemed
quite intuitive.

OTOH, C++ seems like a real non-intuitive mess to me.
[color=blue]
> it feels like the whole class feature was added later.[/color]

Why?
[color=blue]
> The Quick Python book says that Python was designed to be
> object oriented from the ground up. Is it true?[/color]

--
Grant Edwards grante Yow! ... I think I'm
at having an overnight
visi.com sensation right now!!

[John Roth]

Re: Why the 'self' argument?


"Bengt Richter" <bokr@oz.net> wrote in message
news:bjd20a$sf6 $0@216.39.172.1 22...[color=blue]
> On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <newsgroups@jhr othjr.com>[/color]
wrote:[color=blue]
>[color=green]
> >
> >"Grant Edwards" <grante@visi.co m> wrote in message
> >news:3f591d28$ 0$175$a1866201@ newsreader.visi .com...[color=darkred]
> >> In article <vli387c9mm140a @news.supernews .com>, John Roth wrote:
> >>
> >> >> So that there's no difference between a function and a method.
> >> >>
> >> >> Simplicity and orthogonality are good things -- despite what
> >> >> C++ proponents thing.
> >> >>
> >> >> > Hence my comment that requiring it is more complex than not
> >> >> > requiring it.
> >> >>
> >> >> No, it's more complex the Java/Ruby way, since you have to have
> >> >> two sets of rules for what a name means depending on whether
> >> >> you're inside a "normal" function or a method. In Python
> >> >> there's just one set of rules -- mostly.
> >> >
> >> > As I said earlier, it's quite possible to define it so that there
> >> > is always an instance of some kind; whether that's an instance
> >> > a class or the module itself.
> >>
> >> I don't follow. You're talking about defining a keyword that
> >> always refers to the first parameter passed to a function? And
> >> the declared parameters would refer to the 2nd through Nth
> >> parameters? What if the keyword isn't used in the function
> >> definition, then do the delcared parameters refer to the 1st
> >> through Nth?[/color]
> >
> >When Python invokes a function, it binds the operands in the
> >function call to the identifiers named in the function / method
> >header. If this is a method, it binds the instance (which is not
> >in the invocation parameter list, btw.) to the first
> >parameter in the method header.
> >
> >If you make "self" a reserved word, then all it has to do
> >is bind the instance to "self," rather than the first identifier
> >in the parameter list.
> >
> >In current python, there are two classes of functions (module
> >level and embedded) and three classes of methods (instance,
> >class and static.) Instance methods get the current instance,
> >class methods get the class object as the instance, and the other
> >three categories get nothing.
> >
> >As a separate suggestion, I'd have Python bind the module
> >object to "self" for module functions and static methods. I
> >haven't figured out what I want done with embedded methods
> >and unbound methods yet. Notice that this eliminates the
> >need for the global statement for module functions - all
> >identifiers are accessible for rebinding through "self."
> >[color=darkred]
> >> > I think my comments have shown that you can reduce the amount
> >> > of scoping / name space rules noticably.
> >>
> >> Compared to what? It sure sounds like you're introducing more
> >> rules than there are now. How would you propose reducing the
> >> number of rules?[/color]
> >
> >If you don't have to write "self" as the first parameter of a method,
> >that reduces the complexity. Everything else remains the same.[/color]
>
> Will this still be possible?
>[color=green][color=darkred]
> >>> def foo(*args): print args[/color][/color]
> ...[color=green][color=darkred]
> >>> class A(object): pass[/color][/color]
> ...[color=green][color=darkred]
> >>> class B(A): pass[/color][/color]
> ...[color=green][color=darkred]
> >>> a = A()
> >>> b = B()
> >>> A.bar = foo
> >>> b.bar('howdy')[/color][/color]
> (<__main__.B object at 0x00906E70>, 'howdy')[color=green][color=darkred]
> >>> a.bar('howdy')[/color][/color]
> (<__main__.A object at 0x00907170>, 'howdy')[color=green][color=darkred]
> >>> foo('howdy')[/color][/color]
> ('howdy',)
>[color=green][color=darkred]
> >>> A.bar('hello')[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: unbound method foo() must be called with A instance as first[/color]
argument (got str instan[color=blue]
> ce instead)[color=green][color=darkred]
> >>> A.__dict__['bar']('hello')[/color][/color]
> ('hello',)
>
> I.e., the method-vs-function distinction is a matter of how you access the[/color]
function dynamically,[color=blue]
> not how you define it. There is no static distinction in functionality,[/color]
AFAIK (though I guess[color=blue]
> there could possibly be some speculative optimizations).[/color]

It certainly needs to be. One of the reasons I haven't written a PEP is
that providing an instance to an unbound method is a case I don't have
a clear and simple answer to at the moment.
[color=blue]
>[/color]
(The above doesn't even get into the multiple name issues I alluded to).

I don't think the multiple name issues are relevant - that has to do with
how the functions/methods are invoked, rather than what's in the header.)

John Roth[color=blue]
>
> Regards,
> Bengt Richter[/color]

[John Roth]

Re: Why the 'self' argument?


"Harri Pesonen" <fuerte@sci.f i> wrote in message
news:Ucp6b.3992 $ZB4.3874@reade r1.news.jippii. net...[color=blue]
> Jonathan Aquino wrote:[color=green]
> > Two reasons I cringe when I see self as the first parameter of method
> > declarations (i.e. "def methodname(self , ...)" (I don't mind self in
> > the method body)):
> >
> > 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, ...
> >
> > 2) The number of parameters in the method call is one less than the
> > number of parameters in the method declaration. I'm annoyed when I see
> > this because I want the rules of the language to be obvious (in this
> > case, a one-to-one mapping). I would be embarassed to have to explain
> > this to a beginning programmer.
> >
> > (I do like how Python indenting indicates blocks, however)[/color]
>
> I agree, it's not logical. I'm learning Python at the moment, and like
> it very much. This "self" thing seems to be the only odd feature, it
> feels like the whole class feature was added later. The Quick Python
> book says that Python was designed to be object oriented from the ground
> up. Is it true?[/color]

I'm not sure; someone who knows the history back to the beginning
would have to say. However, there's a difference between "from the
ground up," which is certainly true, and "from the beginning" which
may or may not be true.

John Roth
[color=blue]
>
> Harri
>[/color]

[Terry Reedy]

Re: Why the 'self' argument?


"Isaac To" <kkto@csis.hku. hk> wrote in message
news:7ihe3pewu8 .fsf@enark.csis .hku.hk...[color=blue]
> class foo:
> def __init__(msg):
> self.msg = str(msg)
> def f(arg):
> print self.msg + ', ' + str(arg)
> v = foo('hello')
> v.f('world') # equivalent to foo.f(v, 'world')[/color]

I think this equivalence, being an answer to the subject sentence,
needs more emphasis. An instance method is a wrapped function and a
*class* attribute. The 'proper' way to call such functions,
consistent with all other function calls, is klass.meth(inst ,
*rest_of_args), with inst as an explicit first arg matching the
explicit first parameter in the definition. To me, having an explicit
arg match an implicit param would be a warty inconsistency.

From this viewpoint, inst.meth(*rest _of_args) is a conveinient
abbreviation that works because of the attribute inheritance and
lookup mechanism. Of course, beyond being just syntactic sugar, it
adds the very important flexibility of the programmer not having to
know precisely which base class will provide the method. I think the
long form of method call should be taught first, and then the
abbreviation and behavioral reason for its existence. (Perhaps then,
we would have fewer threads on this topic ;-)

If an ad hoc 'self'-rule were added, the inconsistency would have to
be consistently applied to all function definitions. Python attaches
little special importance to the presence of a def within or without a
class suite.
Absent a metaclass override that affects function wrapping only for
those in the .__new__() dict arg but not when later assigned,

class k(object): # or no object
def f(self): pass

nicely abbreviates

def f(self): pass
class k(object): pass
k.f = f
del f

Terry J. Reedy