[Python-Dev] [PEP 576/580] Comparing PEP 576 and 580

[Jeroen Demeyer]

On 2018-07-31 09:36, INADA Naoki wrote:
> I think PEP 580 is understandable only for people who tried to implement
> method objects.

Is this really a problem? Do we expect that all Python developers can 
understand all PEPs, especially on a technical subject like this?

To give a different example, I would say that PEP 567 is also quite 
technical and not understandable by people who don't care about about 
context variables.

If PEP 580 is accepted, we can make it very clear in the documentation 
that this is only meant for implementing fast function/method classes 
and that ordinary "extension writers" can safely skip that part. For 
example, you write

> They should learn PyCCallDef and CCALL_* flags in addition
> to PyMethodDef and METH_*.

but that's not true: they can easily NOT learn those flags, just like 
they do NOT need to learn about context variables if they don't need them.

>> I would like to stress that PEP 580 was designed for maximum
>> performance, both today and for future extensions (such as calling with
>> native C types).
>>
>
> I don't know what the word *stress* mean here.  (Sorry, I'm not good at English
> enough for such hard discussion).
> But I want to see PoC of real benefit of PEP 580, as I said above.

"to stress" = to draw attention to, to make it clear that

So, PEP 580 is meant to keep all existing optimizations for 
functions/methods. It can also be extended in the future (for example, 
to support direct C calling) by just adding extra flags and structure 
fields to PyCCallDef.

> Hm, My point was providing easy and simple way to support FASTCALL
> in callable object like functools.partial or functools.lru_cache.

That can be done easily with only PEP 580.


Jeroen.