On Fri, Nov 9, 2012 at 12:32 AM, Stefan Behnel
<stefan_ml@behnel.de> wrote:
here's an updated proposal, adopting Marc-Andre's improvement that uses a
new field in the PyModuleDef struct to register the callback. Note that
this change no longer keeps up binary compatibility, which may or may not
be acceptable for Python 3.4.
It's not acceptable, as PyModuleDef is part of PEP 384's stable ABI. All such public structures are locked at their original size.
3) The original proposal used a new C-API function to register the callback
explicitly, as opposed to extending the PyModuleDef struct. This has the
advantage of keeping up binary compatibility with existing Py3.3
extensions. It has the disadvantage of adding another indirection to the
setup procedure where a static function pointer would suffice.
Module initialisation is (and must be) part of the stable ABI. Indirection (especially through Python) is a *good* thing, as, ideally, any new interfaces should be defined in a way that doesn't increase the maintenance burden for the stable ABI.
I don't agree that the use of a new init API can fail silently, so long as it completely *replaces* the old API, rather than being an addition. That way, since you won't be defining the *old* init function at all, old versions will correctly refuse to load your module.
So I propose that we simply *fix* extension module loading to work the same way as everything else: the loader creates the module object, and passes it in to a new init function to be fully populated. __file__ and __name__ would be passed in as preinitialised module attributes. The existing PyModule_Create functions would be complemented by a
PyModule_SetDef function which allowed a PyModuleDef to be configured
on a pre-existing module.
Extension modules that wanted to create multiple Python modules would still be free to do so - it would just be up to the extension initialisation code to call PyModule_Create to construct them and set __file__ based on the __file__ of the passed in module.