Where are the attempts to speed up function/method calls? That's an
area where we could *really* use a breakthrough...
At one time you had entertained treating some of the builtin calls as
fixed. Is that something you want to go forward with? It would entail
a from __future__ and transition
Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
[SNIP]
And whatever happened to CALL_METHOD?
It didn't work as an optimization, as far as I remember. I think the
patch is on SF somewhere. Or is a branch in CVS? Oh, it's patch
#709744.
Do we need a tp_callmethod that takes an
At 06:38 PM 2/20/05 +, Michael Hudson wrote:
It folds the two steps into a new opcode. In the case of
store_name/load_name, it saves one three byte instruction, a trip around
the eval-loop, two stack mutations, a incref/decref pair, a dictionary
lookup, and an error check (for the
At 07:00 PM 2/20/05 +, Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
Where are the attempts to speed up function/method calls? That's an
area where we could *really* use a breakthrough...
Amen!
So what happened to Armin's
At 04:32 PM 2/21/05 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
Hm, actually I think I see the answer; in the case of module-level code
there can be no anonymous local variables the way there can in functions.
Why not? There's still a frame object associated with the call
of the anonymous
