[Python-Dev] PEP 590 discussion

Petr Viktorin pviktori at redhat.com
Wed Apr 24 18:25:40 EDT 2019

Hi Mark! See my more general reply; here I'll just tie loose ends with a 
few +1s.

On 4/14/19 7:30 AM, Mark Shannon wrote:
> On 10/04/2019 5:25 pm, Petr Viktorin wrote:
>> PEP 590 is built on a simple idea, formalizing fastcall. But it is 
>> As far as I understand, both are there to avoid intermediate 
>> bound-method object for LOAD_METHOD/CALL_METHOD. (They do try to be 
>> general, but I don't see any other use case.)
>> Is that right?
> Not quite.
> any callable descriptor to benefit from the LOAD_METHOD/CALL_METHOD 
> optimisation.
> PY_VECTORCALL_ARGUMENTS_OFFSET exists so that callables that make onward 
> calls with an additional argument can do so efficiently. The obvious 
> example is bound-methods, but classes are at least as important.
> cls(*args) -> cls.new(cls, *args) -> cls.__init__(self, *args)

I see. Thanks!

>> (I'm running out of time today, but I'll write more on why I'm asking, 
>> and on the case I called "impossible" (while avoiding creation of a 
>> "bound method" object), later.)

Let me drop this thread; I stand corrected.

>> Another point I'd like some discussion on is that vectorcall function 
>> pointer is per-instance. It looks this is only useful for type 
>> objects, but it will add a pointer to every new-style callable object 
>> (including functions). That seems wasteful.
>> Why not have a per-type pointer, and for types that need it (like 
>> PyTypeObject), make it dispatch to an instance-specific function?
> Firstly, each callable has different behaviour, so it makes sense to be 
> able to do the dispatch from caller to callee in one step. Having a 
> per-object function pointer allows that.
> Secondly, callables are either large or transient. If large, then the 
> extra few bytes makes little difference. If transient then, it matters 
> even less.
> The total increase in memory is likely to be only a few tens of 
> kilobytes, even for a large program.

That makes sense.

More information about the Python-Dev mailing list