Home Original page

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

Antoine Pitrou solipsis at pitrou.net
Sat Aug 24 13:53:28 CEST 2013 
On Sat, 24 Aug 2013 21:36:51 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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

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.
More information about the Python-Dev mailing list