On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote: > On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Right. I'm against anything that changes the current semantics. I'm > > all for a compiler optimization that turns "<expr> . <name> ( <args> > > )" into a single opcode that somehow manages to avoid creating the > > bound object. As long as it also does the right thing in case the name > > refers to something that's not quite a standard method -- be it a > > class method or static method, or a class, or anything else callable > > (or even not callable :-). And it would be fine if that optimization > > wasn't used if there are keyword arguments, or *args or **kwds, or > > more than N arguments for some N > 3 or so. > > > > But, as Thomas says, it was tried before and didn't quite work. Maybe > > we can borrow some ideas from IronPython, which boasts a 7x faster > > method call (or was it function call? it was a call anyway); and > > according to Jim Hugunin only half of that speed-up (on a linear or > > logarithmic scale? he didn't say) can be explained through the .NET > > JIT.
> Would a possible special method name __methodcall__ be accepted, where > if it exists on a callable, you can expect to use it as __call__ but > with the understanding that it accepts <expr> as self when called in > an optimizable form? This would reduce the method call to two > attribute lookups before the call instead of an instansiation and all > the heavy lifting currently done. For normal functions, > 'f.__methodcall__ is f.__call__' may be true, but the existance of > that __methodcall__ name just gives you an extra contract. I'd like to answer "no" (since I think this whole idea is not a very fruitful avenue) but frankly, I have no idea what you are trying to describe. Are you even aware of the descriptor protocol (__get__) and how it's used to create a bound method (or something else)? No reply is needed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
