Why do class methods always need 'self' as the first parameter?

[John Roth]

On Sep 1, 8:26 am, Ian Kelly <ian.g.ke... at gmail.com> wrote:
> On Thu, Sep 1, 2011 at 6:45 AM, John Roth <johnro... at gmail.com> wrote:
> > I personally consider this to be a wart. Some time ago I did an
> > implementation analysis. The gist is that, if self and cls were made
> > special variables that returned the current instance and class
> > respectively, then the compiler could determine whether a function was
> > an instance or class method. If it then marked the code object
> > appropriately you could get rid of all of the wrappers and the
> > attendant run-time overhead.
>
> I don't see how you could get rid of the wrappers.  Methods would
> still need to be bound, somehow, so that code like this will work:
>
> methods = {}
> for obj in objs:
>     if obj.is_flagged:
>         methods[obj.user_id] = obj.do_work
>     else:
>         methods[obj.user_id] = obj.do_other_work
> # ...
> methods[some_user_id]()
>
> Without method wrappers, how does the interpreter figure out which
> instance is bound to the method being called?
>
> Cheers,
> Ian

Good question.

Currently the instance wrapper is created during method instantiation,
so the instance is obviously available at that point. There are two
rather obvious ways of remembering it. One is to use the invocation
stack, which has the instance. Another would be for the compiler to
create a local variable for the instance and possibly the class and
fill them in at instantiation time. Both of these require fixing the
names "self" and "cls" so the compiler knows what to do with them. The
first would require giving these two names their own bytecodes, the
second makes them simple local variables the same as the ones in the
method headers. The latter also allows them to be changed by the
method, which is probably not the world's best programming practice
although it's possible now.

John Roth