Why self?

[Matt Gerrans]

> What I mean by the legacy part is that you have to name self in the
> list of arguments to the class methods.
> This part is redundant - but once you are inside a method, it is fine
> that you have to explicitly qualify by self when refering to class
> variables.

I kind of like this part of the syntax, especially when using os.path.walk()
with a walker method in a class; it is very clear what is going on with the
"self" pointer, as opposed to the implicit pointer in C++ which can be
confusing in similar circumstances.

> As holger points out, a frequent source of errors in C++ is that a
> method takes an argument with the same name as a class variable -
> which then hides the class variable.

I don't agree with this argument -- a simple compiler warning solves this
problem; no need to throw out the baby with the bath water.   I also don't
think it is a frequent source of errors.

In Python, I think the required "self" reference in methods is a case where
the solution is worse than the problem it solves.   Since indentation is the
method of scoping in Python, this addition of five characters to each
instance variable is particularly annoying -- a one-line statement that
contains several instance variables can easily become unmanageable.

It's a bit like that horrible blight on the programming community called
"Hungarian Notation" that needlessly polutes code with incomprehensible
variable prefixes so that you know your string is really a long pointer to a
zero terminated array of signed 8-bit characters.   As if you cared, or
needed to be constantly innundated with such superfluous information.
Fortunately, the Hungarian Notation investation has for the most part been
limited to Microsoft's C and C++ APIs and thier usage, but hasn't infected
others -- and nowadays it even seems to be on the decline in Redmond (C#
examples are generally free of it).

I never had a much of problem in C++ with distinguishing member variables
from local variables and I never liked those cheesy ("Some cheese, please,
my good man!") conventions of always using "m_" or "this->".   If you keep
your methods small and clean, you don't need all this slop.

However, since Python doesn't have declarations, some method is required to
distinguish whether an assignment in a class's method is an assignment to a
instance variable or a local variable.   I prefer the solution of simply
making it illegal to have local variable names match class variable names.
Hmm... this doesn't help with the problem of globals, but there is a keyword
for that.

> When I prototype new classes, the methods often start out as
> functions, and typically I forget to add self to the argument list
> when they are promoted to methods.

Me too!