[Python-Dev] PEP 580/590 discussion

[Jeroen Demeyer]

On 2019-03-30 17:30, Mark Shannon wrote:
> 2. The claim that PEP 580 allows "certain optimizations because other
> code can make assumptions" is flawed. In general, the caller cannot make
> assumptions about the callee or vice-versa. Python is a dynamic language.

PEP 580 is meant for extension classes, not Python classes. Extension 
classes are not dynamic. When you implement tp_call in a given way, the 
user cannot change it. So if a class implements the C call protocol or 
the vectorcall protocol, callers can make assumptions about what that means.

> PEP 579 is mainly a list of supposed flaws with the
> 'builtin_function_or_method' class.
> The general thrust of PEP 579 seems to be that builtin-functions and
> builtin-methods should be more flexible and extensible than they are. I
> don't agree. If you want different behaviour, then use a different
> object. Don't try an cram all this extra behaviour into a pre-existing
> object.

I think that there is a misunderstanding here. I fully agree with the 
"use a different object" solution. This isn't a new solution: it's 
already possible to implement those different objects (Cython does it). 
It's just that this solution comes at a performance cost and that's what 
we want to avoid.

> I'll reiterate that PEP 590 is more general than PEP 580 and that once
> the callable's code has access to the callable object (as both PEPs
> allow) then anything is possible. You can't can get more extensible than
> that.

I would argue the opposite: PEP 590 defines a fixed protocol that is not 
easy to extend. PEP 580 on the other hand uses a new data structure 
PyCCallDef which could easily be extended in the future (this will 
intentionally never be part of the stable ABI, so we can do that).

I have also argued before that the generality of PEP 590 is a bad thing 
rather than a good thing: by defining a more rigid protocol as in PEP 
580, more optimizations are possible.

> PEP 580 has the same limitation for the same reasons. The limitation is
> necessary for correctness if an object supports calls via `__call__` and
> through another calling convention.

I don't think that this limitation is needed in either PEP. As I 
explained at the top of this email, it can easily be solved by not using 
the protocol for Python classes. What is wrong with my proposal in PEP 
580: https://www.python.org/dev/peps/pep-0580/#inheritance


Jeroen.