On Sep 1, 8:26 am, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, Sep 1, 2011 at 6:45 AM, John Roth <johnro...@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 -- http://mail.python.org/mailman/listinfo/python-list