[Python-Dev] PEP 580/590 discussion
J.Demeyer at UGent.be
Sat Mar 30 18:36:50 EDT 2019
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
More information about the Python-Dev