[Python-Dev] PEP 590 discussion
Jeroen Demeyer
J.Demeyer at UGent.be
Tue Apr 16 07:15:45 EDT 2019
On 2019-04-03 07:33, Jeroen Demeyer wrote:
> Access to the class isn't possible currently and also not with PEP 590.
> But it's easy enough to fix that: PEP 573 adds a new METH_METHOD flag to
> change the signature of the C function (not the vectorcall wrapper). PEP
> 580 supports this "out of the box" because I'm reusing the class also to
> do type checks. But this shouldn't be an argument for or against either
> PEP.
Actually, in the answer above I only considered "is implementing PEP 573
possible?" but I did not consider the complexity of doing that. And in
line with what I claimed about complexity before, I think that PEP 580
scores better in this regard.
Take PEP 580 and assume for the sake of argument that it didn't already
have the cc_parent field. Then adding support for PEP 573 is easy: just
add the cc_parent field to the C call protocol structure and set that
field when initializing a method_descriptor. C functions can use the
METH_DEFARG flag to get access to the PyCCallDef structure, which gives
cc_parent. Implementing PEP 573 for a custom function class takes no
extra effort: it doesn't require any changes to that class, except for
correctly initializing the cc_parent field. Since PEP 580 has built-in
support for methods, nothing special needs to be done to support methods
too.
With PEP 590 on the other hand, every single class which is involved in
PEP 573 must be changed and every single vectorcall wrapper supporting
PEP 573 must be changed. This is not limited to the function class
itself, also the corresponding method class (for example,
builtin_function_or_method for method_descriptor) needs to be changed.
Jeroen
More information about the Python-Dev
mailing list