[Python-Dev] PEP 573 -- Module State Access from C Extension Methods (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Apr 24 08:53:26 EDT 2018

On 24 April 2018 at 18:17, Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

In PEP 573, instead of passing the defining class to the C function, why not pass the function object itself? That is far more general: once you have the function object, you can still access the defining class using your PyCMethodCLASS. It's also more future-proof: if we ever decide to add even more attributes to the function object, those could be accessed the same way.

In PEP 575, I'm already proposing a flag (METHARG0FUNCTION) to pass the function instead of self. Unless PEP 573 is rejected, maybe that should change to passing the function in addition to self.

That would definitely be an elegant way of addressing both use cases.

Of course, this doesn't quite work with your current version of PEP 573 since METHMETHOD really does two things: it changes the class of the function object (which is not a good idea anyway) and it changes the calling convention. It could work if you add mmclass to PyCFunctionObject instead of creating a new class.

Creating a new type in the module state access aimed to reduce the potential for unintended side effects, but assuming we go ahead with PEP 575's restructuring of the native function class heirarchy, I agree it would make more sense to add it as a new capability within that heirarchy, rather than adding a dedicated type for it.

Regarding the module state access PEP overall - I'm +1 on the proposed changes (the PEP's been through a number of earlier rounds of discussion on import-sig, and my feedback from those has already been incorporated into the current version).

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list