[Python-Dev] CALL_ATTR, A Method Proposal

[Guido van Rossum]

> 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 CALL_ATTR.

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

I'm all for making the bytecode compiler recognize the special case
<object>.<name>(<args>), 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(<object>, "<name>")(<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/)