Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why the 'self' argument?

Reply
Thread Tools

Why the 'self' argument?

 
 
Alex Martelli
Guest
Posts: n/a
 
      09-06-2003
Grant Edwards wrote:
...
>> 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.


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

 
Reply With Quote
 
 
 
 
Dave Brueck
Guest
Posts: n/a
 
      09-06-2003
On Saturday 06 September 2003 02:17 pm, Terry Reedy wrote:
> The main virtue of the inst.meth(*rest) abbreviation, with klass made
> implicit, is not just to save typing the klass name but to push
> determination of which 'klass' to the runtime inheritance tree,


Pardon me if this was mentioned previously, but another benefit is to simplify
the process of passing methods or stand-alone functions around - the user of
such functions doesn't have to differentiate between the two:

class Foo:
def OnEvent(self, a, b):
print 'Method', a, b

def Listener(a, b):
print 'Function', a,b

def SomeEventGenerator(eventListener):
eventListener(5, 6)

SomeEventGenerator doesn't care if the callback is actually a method or a
function. Both these work just fine:

f = Foo()
SomeEventGenerator(foo.OnEvent)
SomeEventGenerator(Listener)

Obviously, if the shorthand inst.meth(*rest) wasn't available there would
probably be another way to do the same thing, but "inst.meth" is concise and
does what you'd expect.

-Dave

 
Reply With Quote
 
 
 
 
Michael Peuser
Guest
Posts: n/a
 
      09-06-2003

"John Roth" <(E-Mail Removed)>

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


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

Kindly
Michael P


 
Reply With Quote
 
Isaac To
Guest
Posts: n/a
 
      09-06-2003
>>>>> "Michael" == Michael Peuser <(E-Mail Removed)> 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.
 
Reply With Quote
 
Bengt Richter
Guest
Posts: n/a
 
      09-06-2003
On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <(E-Mail Removed)> wrote:

>
>"Grant Edwards" <(E-Mail Removed)> wrote in message
>news:3f591d28$0$175$(E-Mail Removed). ..
>> In article <(E-Mail Removed)>, 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?

>
>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."
>
>> > 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?

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


Will this still be possible?

>>> def foo(*args): print args

...
>>> class A(object): pass

...
>>> class B(A): pass

...
>>> a = A()
>>> b = B()
>>> A.bar = foo
>>> b.bar('howdy')

(<__main__.B object at 0x00906E70>, 'howdy')
>>> a.bar('howdy')

(<__main__.A object at 0x00907170>, 'howdy')
>>> foo('howdy')

('howdy',)

>>> A.bar('hello')

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)
>>> A.__dict__['bar']('hello')

('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
 
Reply With Quote
 
Jonathan Aquino
Guest
Posts: n/a
 
      09-06-2003
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)
 
Reply With Quote
 
Harri Pesonen
Guest
Posts: n/a
 
      09-06-2003
Jonathan Aquino wrote:
> 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)


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

 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-06-2003
In article <Ucp6b.3992$(E-Mail Removed)>, Harri Pesonen wrote:

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

> it feels like the whole class feature was added later.


Why?

> The Quick Python book says that Python was designed to be
> object oriented from the ground up. Is it true?


--
Grant Edwards grante Yow! ... I think I'm
at having an overnight
visi.com sensation right now!!
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      09-06-2003

"Bengt Richter" <(E-Mail Removed)> wrote in message
news:bjd20a$sf6$0@216.39.172.122...
> On Fri, 5 Sep 2003 20:15:00 -0400, "John Roth" <(E-Mail Removed)>

wrote:
>
> >
> >"Grant Edwards" <(E-Mail Removed)> wrote in message
> >news:3f591d28$0$175$(E-Mail Removed). ..
> >> In article <(E-Mail Removed)>, 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?

> >
> >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."
> >
> >> > 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?

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

>
> Will this still be possible?
>
> >>> def foo(*args): print args

> ...
> >>> class A(object): pass

> ...
> >>> class B(A): pass

> ...
> >>> a = A()
> >>> b = B()
> >>> A.bar = foo
> >>> b.bar('howdy')

> (<__main__.B object at 0x00906E70>, 'howdy')
> >>> a.bar('howdy')

> (<__main__.A object at 0x00907170>, 'howdy')
> >>> foo('howdy')

> ('howdy',)
>
> >>> A.bar('hello')

> 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)
> >>> A.__dict__['bar']('hello')

> ('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).


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.

>

(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
>
> Regards,
> Bengt Richter



 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      09-06-2003

"Harri Pesonen" <(E-Mail Removed)> wrote in message
news:Ucp6b.3992$(E-Mail Removed).. .
> Jonathan Aquino wrote:
> > 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)

>
> 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?


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

>
> Harri
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments