The need to put "self" in every method

[spinach]

Explicit is better than implicit.

import sarcasm

def whatAboutMyImplicitModuleMethod()

 

[Peter Maas]

i was just wondering about the need to put "self" as the first
parameter in every method a class has because, if it's always needed,
why the obligation to write it? couldn't it be implicit?

Or is it a special reason for this being this way?

See section 1.4.4 in http://www.python.org/doc/faq/general.html

 

[Peter Maas]

Because Python has no declarations there must be a different way to
indicate in which category an identifier falls.

[...]
Any objection to swiping this for the FAQ? (Probably with some minor
edits.)

There is already a 'self' section (1.4.4) in the official Python FAQ.
Looks like this has been forgotten. Perhaps it would be helpful to
create a short version of the FAQ with the top most frequently asked
questions/stumbling blocks/annoyances titled "top 10 things you always
wanted to know about Python and didn't dare to ask" and post it weekly
in this newsgroup

 

[Aahz]

Because Python has no declarations there must be a different way to
indicate in which category an identifier falls.

[...]
Any objection to swiping this for the FAQ? (Probably with some minor
edits.)

There is already a 'self' section (1.4.4) in the official Python FAQ.
Looks like this has been forgotten. Perhaps it would be helpful to
create a short version of the FAQ with the top most frequently asked
questions/stumbling blocks/annoyances titled "top 10 things you always
wanted to know about Python and didn't dare to ask" and post it weekly
in this newsgroup

Ahhh... I looked in the Programming FAQ, but not the General FAQ. I
still think that section could use some clarification based on Piet's
wording, but it's less urgent.

 

[Ron Adam]

Hi,

i was just wondering about the need to put "self" as the first
parameter in every method a class has because, if it's always needed,
why the obligation to write it? couldn't it be implicit?

Or is it a special reason for this being this way?

Thanks.

Here's how I view it... (It may not be strictly correct, so corrections
are welcome.)

It helps to think of new style class's as code patterns or templates to
create class-instance objects. Since you don't know what the name of
the instance object is going to be when you write the class, a way to
refer to the contents of the not yet created object is needed.

Passing the class-instance reference as the first argument is how Python
gets a reference to the local name space of the method. You can then
use that name to access the other objects in the class-instance or to
create new objects in the class-instance from within the method without
knowing what the class-instance name is before hand.

Python doesn't pass the 'self' reference when a locally defined function
is called inside a class or method. By having to *explicitly* receive
the 'self' reference in the argument list, it is clear when the 'self'
reference is available for use and when it's not.

Cheers,
_Ron_Adam

 

[Aahz]

No.
The global/local stuff needs a bit more nuance (assignments in the method
being the criterium).

Done! Thanks for prodding the update.

 

[D H]

One reason is because of the dynamic nature of Python classes. You can
attach new methods to a class after it is instantiated, or remove
methods. The language boo (http://boo.codehaus.org/) has classes
defined at compile time, and there "self" is not needed at all. If you
want to use the duck typing features in boo, however, and re-implement
python-like dynamic classes that can have methods removed or added at
any time, then your methods need some kind of "self" parameter so they
can access the context of their class instance, because really there is
no special relationship between the methods and the class unless you
explicitly specify it.

The reason can be found in the output from the python statement "import
this". Explicit is better than implicit.

Like those invisible yet explicit scope indicators, tabs and spaces.