On Sat, 24 Aug 2013 21:36:51 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 24 August 2013 15:51, Nick Coghlan <ncogh...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
