[Python-Dev] Pre-PEP: Redesigning extension modules

Nick Coghlan ncoghlan at gmail.com
Sat Aug 24 13:36:51 CEST 2013


On 24 August 2013 15:51, Nick Coghlan <ncoghlan at gmail.com> 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_imports

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

These cover setting the docstring and adding module level functions,
tasks that are handled through the PyModule_Create API when using the
PyInit_NAME style hook.

The _testimportexec.c module was derived from the existing example
xxlimited.c module, with a few name changes. The main functional
difference is that _testimportexec uses the new API, so the module
object is created externally and passed in to the API, rather than
being created by the extension module. The effect of this can be seen
in the test suite, where ImportExecTests.test_fresh_module shows that
loading the module twice will create two *different* modules, unlike
the legacy API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list