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