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

Jeroen Demeyer 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 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.lrucache.

That can be done easily with only PEP 580.

Jeroen.

More information about the Python-Dev mailing list