"self" - a python wart or "feature"

Kaz Kylheku kaz at ashi.footprints.net
Mon Feb 17 13:29:15 EST 2003


ceremona2000 at yahoo.com (Cere Davis) wrote in message news:<e32daabb.0302162004.6f7ceabf at posting.google.com>...
> Why bother requiring the
> self keyword in every stinkin' method?  This seems klunky to me but
> perhaps there is something I am missing here.

Yes. What you are missing is that in order to get rid of the explicit
self, you have to introduce the incredibly brain-damaged notion of
``class scope''.

Class scope is the stupidest thing to come out of programming language
academia since the Pascal WITH construct.

What both of these pieces of idiocy share is this: that a magic
incantation in the program causes some remote lexical scope to be
combined into the present scope. Suddenly, changes in that remote
scope affect the meaning of the local scope!

In the Pascal WITH construct, you can do something like this:

   WITH structure1 BEGIN
      WITH structure2 BEGIN
         ...
      END
   END

Inside the nesting, you can refer to the fields of the structures
using their short name only; instead of structure1.x you just write x.

In other words, the field memberships of both structures have been
effectively fused into the present scope, combining with the lexical
scope.

Can you see the problems?

What if you have some local variable Z? Everything is fine because
neither structure1 nor structure2 have a member of that name. Then
someone who doesn't know about your piece of code here adds such a
member to one of the structures.

Or what if structure1 initially has a member Y, but structure2 does
not. Then later structure2 does acquire a member Y. Oops; references
to Y in such nested WITH constructs now silently change reference.

The C++ class scope is exactly like one nesting level of the pascal
WITH construct. It effectively places a ``with *this'' around your
entire function.

This is all wrong. The content of the scope should be entirely under
the programmer's control. Any programming language which causes an
identifier to acquire a binding should take that identifier as a
parameter.

The Modula 3 language has a much more sane WITH construct. It's
basically a local macro system which allows you to give nicknames to
expressions. The syntax is something along these lines:

   WITH cell = a[i, j], neighbor = a[i, j + 1] BEGIN
      (* okay, ``cell'' and ``neighbor'' visible here as syntactic
sugar
         for a[i, j] and a[i, j + 1]. *)
   END

See the difference? The content of the scope is under the programmer's
control. You choose the names.

As a result, the program can have one nice property: the meaning of
every identifier can be traced to some lexically enclosing binding
construct. Failing that, it has a definition in some global
environment, or no definition at all.




More information about the Python-list mailing list