[Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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
> PyCMethod_CLASS. 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 (METH_ARG0_FUNCTION) 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 METH_METHOD 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 mm_class 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