Re: Module state access from extension methods

Nick Coghlan <[email protected]> Tue, 27 Mar 2018 22:29:18 +1000
Newsgroups gmane.comp.python.import
Message-ID <CADiSq7cKZhO0ge19z2oLDD+6k-h8kK2CsRuj9Qg0hwqxaR3J+w@mail.gmail.com>
On 24 March 2018 at 01:09, Marcel Plch <[email protected]> wrote:
> There was a conversation about this matter on this list some while
> ago. There should be people here that remember it, so I am sending it
> here before sending it to python-ideas.
>
> I have a PEP draft prepared for allowing type methods in C extensions
> access to per-module state. This should solve some problems of PEP 489
> multiphase initialization.

Thanks for putting this together! I've merged the PEPs repo PR as PEP
573: https://github.com/python/peps/blob/master/pep-0573.rst

For the slot methods situation, given that PEP 567's context vars
landed in Python 3.7, I think it may be worth mentioning that those
are another reason to defer doing anything too drastic about access to
module global state from slot implementations - it's quite possible
that the performance of walking the MRO once-per-type-per-context and
then caching the result in a context variable will turn out to be
sufficient for the cases that need better performance than plain MRO
walking offers.

A similar consideration applies to all the optimised function call
variants - making heap types aware of their defining module has
inherent introspection and identification benefits, and once we have
that, adding METH_METHOD makes sense. But folks that opt for one of
the optimised call variants instead will still have the same
MRO-walking approach available as slot method implementations do, so
any context variable based caching scheme defined for those should
also work for other methods that aren't using the METH_METHOD call
signature.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia