Why the 'self' argument?

[Grzegorz Staniak]

Hello,

I'm a newbie Python user, a systems administrator - I've been trying
to switch from Perl to Python for administrative tasks - and one thing
I cannot understand so far is why I need the special 'self' (or anything
esle) argument in class method definitions. I might have missed an
explanation in the docs, a quick Google search did not help. Is there
somewhere on the web you could direct me to?

Thanks,

 

[=?ISO-8859-1?Q?Gerhard_H=E4ring?=]

Hello,

I'm a newbie Python user, a systems administrator - I've been trying
to switch from Perl to Python for administrative tasks - and one thing
I cannot understand so far is why I need the special 'self' (or anything
esle) argument in class method definitions. I might have missed an
explanation in the docs, a quick Google search did not help. Is there
somewhere on the web you could direct me to?

This entry of the Python FAQ:

http://www.python.org/doc/faq/gener...ed-explicitly-in-method-definitions-and-calls

-- Gerhard

 

[vivek]

Hello,

I'm a newbie Python user, a systems administrator - I've been trying
to switch from Perl to Python for administrative tasks - and one thing
I cannot understand so far is why I need the special 'self' (or anything
esle) argument in class method definitions. I might have missed an
explanation in the docs, a quick Google search did not help. Is there
somewhere on the web you could direct me to?

Thanks,

The first argument in a class method is a reference to that class itself. It is
same as "this" pointer in c++ and java. Using this argument you can access the
class variables. ex:

class test:
def __init__(self,arg1,arg2): #this acts as class constructor
self.name=arg1
self.value=arg2


def changeName(self,newName): #here we change the name class variable
self.name=newName
..........and so on

regards
Vivek Kumar

 

[Lukasz Pankowski]

Hi,

the answer is in python FAQ:

http://python.org/doc/faq/general.h...ed-explicitly-in-method-definitions-and-calls

 

[Grant Edwards]

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.

 

[John Roth]

It would also make the language more complex and irregular.

How?

John Roth

 

[Grant Edwards]

How?

1) It would add a reserved word.

2) It would mean that there's some sort of difference between
a function and a method.

 

[Alex Martelli]

The first argument in a class method is a reference to that class itself.

Yes, that's what defines CLASS methods (as opposed to ordinary, or
INSTANCE, methods). But the original poster was not asking about class
methods, and you're not giving any examples of them -- I only see
instance methods. I suspect a terminology problem -- you may be using
the term "class method" in a way that is totally inappropriate to
Python, where classes are first-level objects.


So -- in Python, you see...:

To make a class method you have to call on the classmethod built-in. E.g.:

class Example(object):

def instmeth(self): print 'Instance method of', self

def clasmeth(cls): print 'Class method of', cls
clasmeth = classmethod(clasmeth)

inst = Example()


Now you can call:

inst.instmeth()

or:

inst.clasmeth()
Example.clasmeth()

(both of these do exactly the same thing), but NOT:

Example.instmeth()

since an INSTANCE method, differently from a CLASS method,
needs to be passed the instance as the first argument, either
implicitly (by CALLING it on the instance) or explicitly
by passing it when calling the method on the class, as in:

Example.instmeth(inst)


Alex

 

[John Roth]

1) It would add a reserved word.

So? For most people, self *is* a reserved word anyway. A lot of
novices think it is. Making it official simplifies things, IMO.

2) It would mean that there's some sort of difference between
a function and a method.

I don't understand your point. There is currently a difference
between a function and a method that could be eliminated by
making self a reserved word and removing it from the method
header. Or have you never tried to invoke a method from the
wrong context and gotten the "unbound method" error?

There's no reason why a function in the module space couldn't
use self to refer to the module. It would simplify things by
removing much of the need for the global keyword.

John Roth

 

[John Roth]

There's no difference in the sense that a method is
simply a function whose first parameter refers to the class
instance to be worked on. No magic words, no "undeclared"
parameters. It means that in my demo code in limitcases.py
(somewhere in the newsgroup lately) I can say

limitcases.Lowest.__str__ = lambda x: "-Infinity"

to give the Lowest class a new method sans ennuis.

But why do it that way? Neither Java nor Ruby require
giving the instance a name. Hence my comment that requiring
it is more complex than not requiring it.

John Roth

 

[Michael Peuser]

I'm a newbie Python user, a systems administrator - I've been trying
to switch from Perl to Python for administrative tasks - and one thing
I cannot understand so far is why I need the special 'self' (or anything
esle) argument in class method definitions.

You probably do not mean "class methods"; this a technical term in OOP.

The Python class basics are *very* similar to the implementation of Perl
classes!!
You should not have much problems....

Kindly
Michael P

 

[Grant Edwards]

But why do it that way?

So that there's no difference between a function and a method.

Simplicity and orthogonality are good things -- despite what
C++ proponents thing.

Neither Java nor Ruby require giving the instance a name.

So?

Personally I don't like invisible, implied, automatic stuff
like that.

Can't stand automatic transmissions either -- the damn things
have no idea what's ahead, and always seem to be in the wrong
gear at critical moments.

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.

I have enough trouble remembering how the stuff I design works.

I don't want to have to keep track of more scoping/name-space
rules than absolutely necessary.

 

[Bengt Richter]

You probably do not mean "class methods"; this a technical term in OOP.

I suspect the OP meant "class (method definitions)," not "(class method)" definitions." ;-)

Re "self," there must be a FAQ entry, but I'm too lazy to look for it.

Regards,
Bengt Richter

 

[John Roth]

So that there's no difference between a function and a method.

Simplicity and orthogonality are good things -- despite what
C++ proponents thing.


So?

Personally I don't like invisible, implied, automatic stuff
like that.

Can't stand automatic transmissions either -- the damn things
have no idea what's ahead, and always seem to be in the wrong
gear at critical moments.


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 have enough trouble remembering how the stuff I design works.

I don't want to have to keep track of more scoping/name-space
rules than absolutely necessary.

I think my comments have shown that you can reduce the
amount of scoping / name space rules noticably.

John Roth

 

[John Roth]

You probably do not mean "class methods"; this a technical term in OOP.

The Python class basics are *very* similar to the implementation of Perl
classes!!
You should not have much problems....

Actually, I think he *does* mean "class methods." They are new in 2.2
after all, and I missed the qualification the first time around.

John Roth

 

[Grant Edwards]

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?

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?

 

[John Roth]

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

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.

John Roth

 

[Bengt Richter]

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

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]

[...]

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

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

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

 

[Paul Foley]

1) It would add a reserved word.

2) It would mean that there's some sort of difference between
a function and a method.

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>"))