[Python-Dev] CALL_ATTR, A Method Proposal

Finn Bock bckfnn@worldonline.dk
Fri, 14 Feb 2003 14:02:34 +0100


[Glyph Lefkowitz on __callattr__]

> CALL_ATTR should be implementable with no impact on existing python code,
> except bytecode hacks.  It should be possible to retain a fully
> backwards-compatible __getattr__ method, for places where method objects are
> used (including the C API).  Likewise, the default __callattr__ could be set up
> to first check if __getattr__ is defined, then the instance's dictionary or
> __slots__.  For additional speed gains, new-object-model classes could set
> '__fast_methods__ = True' and gain a semantic distinction between __getattr__
> and __callattr__.
> 
> Better still, I think that Jython could use the subtle semantic change
> to make Java reflection less expensive.  (Java's `new' is more expensive than
> C's `malloc', after all.)

For the record, jython already have invoke(...) (what you call 
__callattr__) and uses it to optimize certain simple method calls on 
instances. It is not currently used to optimize calls into java reflection.

Oh, as a cute aside, when I tried to run your timing program, I realized 
that the optimization had been disabled by mistake in CVS during the AST 
parse tree rewrite. Thanks for your help in pointing that out.

Without the "invoke" optimization, I get these numbers:

    2.865000009536743
    1.7020000219345093

With the optimization added, I get this:

    2.052999973297119
    1.652999997138977

regards,
finn