From gmarcel.plch at gmail.com Fri Mar 23 11:09:12 2018 From: gmarcel.plch at gmail.com (Marcel Plch) Date: Fri, 23 Mar 2018 16:09:12 +0100 Subject: [Import-SIG] Module state access from extension methods Message-ID: 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. conversation - https://mail.python.org/pipermail/import-sig/2015-July/001022.html PEP - https://github.com/Traceur759/pep-drafts/blob/master/pep-C.rst Implementation - https://github.com/Traceur759/cpython/pull/4 From ncoghlan at gmail.com Tue Mar 27 08:29:18 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 27 Mar 2018 22:29:18 +1000 Subject: [Import-SIG] Module state access from extension methods In-Reply-To: References: Message-ID: On 24 March 2018 at 01:09, Marcel Plch 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 | ncoghlan at gmail.com | Brisbane, Australia