[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 576bis discussion

By lack of a better name, I'm using the name PEP 576bis to refer to
(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.