[Python-Dev] [PEP 576/580] Comparing PEP 576 and 580 (original) (raw)

INADA Naoki songofacandy at gmail.com
Tue Jul 31 10:00:13 EDT 2018


On Tue, Jul 31, 2018 at 9:55 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

On 2018-07-31 12:10, INADA Naoki wrote: > Surely, they should understand they must use CCALL* flags instead of > METH* flags when implementing fast-callable object. Yes indeed. But implementing a fast-callable object is quite specialized, not something that ordinary extension writers would care about. And if they don't care about performance, tpcall remains supported. More generally: with PEP 580, everything from the documented C API remains supported. So people can write extensions exactly as before. They only need to care about PEP 580 if they want to use the new features that PEP 580 adds (or if they used undocumented internals).

Jeroen.

100% agree. I never claimed fastcall support for callable object is important.

From my first mail in this thread, I prefer PEP 580, although I was not 100% sure PEP 580 is better.

My point (why I'm not 100% sure PEP 580 is better) was simplicity / straightforwardness. I just explained it as "understandability for extension author".

Method types (PyCFunction / CyFunction / method_descripter, etc) are callable type. So

"make simple and fast callable protocol, then implement complicated method types behind the protocol".

seems much straightforward than

"Add complicated protocol for method types, then callable can be implemented like method type".

If there are no drawback in PEP 576, CCall can be used behind it like:

.tp_ccalloffset = offsetof(...), .tp_extcall = PyCCall_ExtCall, // filled by PyType_Read()

But PEP 576 is not perfect:

That's why I prefer PEP 580. When I wrote first mail in this thread in last week, I'm about 70% sure. Since I can't find performance critical "tp_call" usage (*), I'm 90% sure for now.

(*) Actually speaking, I think tp_new is called more often than tp_call.

-- INADA Naoki <songofacandy at gmail.com>



More information about the Python-Dev mailing list