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

Reply via email to