On Fri, Nov 9, 2012 at 12:32 AM, Stefan Behnel <stefan...@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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ 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
