> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4