[Python-Dev] CALL_ATTR, A Method Proposal (original) (raw)

Guido van Rossum guido@python.org
Fri, 14 Feb 2003 13:01:48 -0500

My proposal is to treat method calls as syntactically different from function calls. Rather than x.y() being completely synonymous with getattr(x, "y")(), it could be analogous to 'x.y = z' or 'del x.y'. For symmetry with these statement types, the new bytecode could be called CALLATTR.

I'm not sure exactly what you're proposing here.

I'm all for making the bytecode compiler recognize the special case .(), and emitting a special bytecode for it that can be executed more efficiently in the common case.

But I want the semantic definition to be unchanged: it should really mean the same thing as gettattr(, "")(<args).

This may limit the possibilities for optimization, but any change in semantics for something as fundamental as this is going to break too much stuff. Besides, I think that semantic definition is exactly right.

Here's how I think the CALL_ATTR opcode should work:

if <obj> is a new instance:
   if the class's getattr policy is standard:
      if <name> not in <obj>.__dict__:
         search <obj>.__class__ and its base classes for <name>
         if found and the result is a Python function:
             call it with arguments (<obj>, <args>) and return
elif <obj> is a classic instance:
   if <name> not in <obj>.__dict__:
      search <obj>.__class__ and its base classes for <name>
      if found and the result is a Python function:
          call it with arguments (<obj>, <args>) and return
# if we get here, the optimization doesn't apply
tmp = getattr(<obj>, <name>)
return tmp(<args>)

--Guido van Rossum (home page: http://www.python.org/~guido/)