git.net

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

[Python-Dev] PEP 590 discussion


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