[Python-Dev] PEP 576bis discussion (original) (raw)

Jeroen Demeyer J.Demeyer at UGent.be
Wed Mar 27 11:13:10 EDT 2019

By lack of a better name, I'm using the name PEP 576bis to refer to https://github.com/markshannon/peps/blob/new-calling-convention/pep-9999.rst (This is why this should get a PEP number soon, even if the PEP is not completely done yet).

On 2019-03-27 14:50, Petr Viktorin wrote:

The pre-PEP is simpler then PEP 580, because it solves simpler issues. I'll need to confirm that it won't paint us into a corner -- that there's a way to address all the issues in PEP 579 in the future.

One potential issue is calling bound methods (in the duck typing sense) when the LOAD_METHOD optimization is not used. This would happen for example when storing a bound method object somewhere and then calling it (possibly repeatedly). Perhaps that's not a very common thing and we should just live with that. However, since self is part of the PEP 580 protocol, it allows calling a bound method object without any performance penalty compared to calling the underlying function directly.

Similarly, a follow-up of PEP 580 could allow zero-overhead calling of static/class methods (I didn't put this in PEP 580 because it's already too long).

As far as I can see, PEP 580 claims not much improvement in CPython, but rather large improvements for extensions (Mistune with Cython).

Cython is indeed the main reason for PEP 580.

The pre-PEP has a complication around offsetting arguments by 1 to allow bound methods forward calls cheaply.

I honestly don't understand what this "offset by one" means or why it's useful. It should be better explained in the PEP.

The pre-PEP's "any third-party class implementing the new call interface will not be usable as a base class" looks quite limiting.

I agree, this is pretty bad. However, I don't think that there is a need for this limitation. PEP 580 solves this by only inheriting the Py_TPFLAGS_HAVE_CCALL flag in specific cases. PEP 576bis could do something similar.

Finally, I don't agree with this sentence from PEP 576bis: PEP 580 is specifically targetted at function-like objects, and doesn't support other callables like classes, partial functions, or proxies.

It's true that classes are not supported (and I wonder how PEP 576bis deals with that, it would be good to explain that more explicitly) but other callables are not a problem.

Jeroen.

More information about the Python-Dev mailing list