[Python-Dev] PEP 580/590 discussion
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
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
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