[Python-Dev] [PEP 576/580] Comparing PEP 576 and 580
J.Demeyer at UGent.be
Tue Jul 31 05:07:26 EDT 2018
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
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.
More information about the Python-Dev