use of "self", was "No Do while/repeat until looping construct in python?"

John Roth johnroth at
Sat Mar 15 14:44:38 CET 2003

"William Sonna" <wsonna at> wrote in message
news:pan.2003. at
> On Fri, 14 Mar 2003 13:20:53 -0500, Chermside, Michael wrote:
> >> On the other hand, if you have a valid reason why "self" is
> >> advantageous FROM THE USER's POINT OF VIEW I would like to hear it.
> >
> > I'm not sure I really believe you (about desiring to hear a reason
> > "self" is advantageous), but I'll give it a shot anyhow.
> >
> > Consider the following Java snippet (sorry, I don't know Ruby well
> > enough to get the syntax right).
> >
> >     public class MyClass extends ParentClass {
> >         String accessId;
> >         public MyClass(accessId) {
> >             this.accessId = accessId;
> >         }
> >         public int overlyLongFunction() {
> >             // Here goes 162 lines of messy code
> >             return (jiggerPercent > 100) ? 100 : jiggerPercent;
> >         }
> >         }
> >         }
> > In the last line of overlyLongFunction, we refer to the variable
> > "jiggerPercent". This could be either a local variable OR an
> > variabler... and there's no way to tell which one it is. Notice how
> > constructor uses a common java idiom which makes use of this

Java isn't a good comparison language for the simple reason
that it won't compile unless there is ***complete*** knowledge of
every name and how it is used. This goes beyond static typing. It means
compiler knows whether a name is local or instance.

> Yes, the constuctor is clear as can be.  The rules in Java are also
> as can be, and evey bit as clear as the self in Python - local
> or function parameters overshadow instance variables of the same name.
> I am not troubled at all by the enhanced clarity that self provides.

> What I am sick of is getting nailed by the interpreter for forgetting
> add "self" to every lousy instance variable name - or even worse -
> it treat my omission as a local variable.  The mandatory self is
itself a
> source of errors, and I believe based on my own experience that it
> more errors than it prevents.

Different people have different experiances of that - it's a personal
thing. However, I do agree that it is a fertile source of errors.

> Call it a feature if you will, but my guess is that its an
> requirement that has a side benefit for those who like mandatory
> qualification.

No, the reason for the qualification has more to do with unambiguously
figuring out what you want it to do. See my comment about Java above.

Python has six commingled name spaces:

1. The local name space, from the local function
2. The free variable name space, from functions in the calling chain
3. The instance name space, using the usual inheritance rules
4. The module name space.
5. The global name space.
6. The predefined symbol name space (e.g. "if", "else")

Using 'self' makes it possible to refer directly to the instance
name space without special rules. You can't, for example change
anything in the free variable name space, and you need a declaration
to change anything in the module name space. There are other things
you need to do to change things in the global name space, and it's
impossible to change things in the predefined symbol space.

Ruby, for example, requires a "funny character" to distinguish
instance variables and module/global variables from local variables.
It borrowed the concept from Perl, although for a very different use.

> > In Python, it would refer to either "jiggerPercent" or to
> > "self.jiggerPercent", and the reader would be immediately aware of
> > was intended. (Note that Python values terseness for the sake of the
> > READER of the code, not because the WRITER of the code has lazy
> > fingers.)
> >
> > Of course, Python isn't perfect in this regard... it still has three
> > different namespaces (local, global, built-in) where the variable
> > live, but at least it distinguishes the instance-variable namespace.
> >
> >
> The biggest problem I have personally found with name pollution is
> tracking hand-me-down names from base classes I know nothing about.
> Unfortunately, while "self" helps a tiny bit, it doesn't really solve
> problem.
> > You can argue over whether you LIKE this feature, but it IS a
> > commonly-mentioned advantage of the use of self. Now you said that
> > "common sense says the instance variables are local", but I believe
> > is a very odd use of the term of "common sense", given that instance
> > variables are _NOT_ the same as local variables... not in Python, in
> > Java, or in Ruby. Doesn't mean you have to like typing "self", but
it IS
> > one good reason (among others) for requiring it.
> >
> >
> Instance variables are accessed identically to local variables within
> mehtods in virtually every other major programming language in use
> Wouldn't you call that common?

That's true only for languages that require all of the variables to be
availible at compile time. It's not true for languages like Ruby or

This is, frankly, a problem that I'd expect an intelligent IDE to solve
with syntax highlighting. That is, what I'd really like to see is an
that tells me something is an instance variable with color, and suppress
the self. from the screen.

Of course, there are other things I'd like to see in the IDE as well...

John Roth

More information about the Python-list mailing list