On Sat, 24 Aug 2013 21:36:51 +1000
Nick Coghlan
On 24 August 2013 15:51, Nick Coghlan
wrote: My current plan is to create an experimental prototype of this approach this weekend. That will include stdlib test cases, so it will also show how it looks from the extension developer's point of view.
I prototyped as much as I could without PEP 451's ModuleSpec support here:
https://bitbucket.org/ncoghlan/cpython_sandbox/commits/branch/new_extension_...
On systems that use dynload_shlib (at least Linux & the BSDs), this branch allows extension modules to be imported if they provide a PyImportExec_NAME hook. The new hook is preferred to the existing PyInit_NAME hook, so extension modules using the stable ABI can provide both and degrade to the legacy initialisation API on older versions of Python.
The PyImportExec hook is called with a pre-created module object that the hook is then expected to populate. To aid in this task, I added two new APIs:
PyModule_SetDocString PyModule_AddFunctions
I was thinking about something like PyType_FromSpec, only specialized for module subclasses to make it easier to declare them (e.g. PyModuleType_FromSpec). This would also imply extension module have to be subclasses of the built-in module type. They can't be arbitrary objects like Stefan proposed. I'm not sure what the latter enables, but it would probably make things more difficult internally. Regards Antoine.