<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 9, 2012 at 12:32 AM, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de" target="_blank">stefan_ml@behnel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

here's an updated proposal, adopting Marc-Andre's improvement that uses a<br>
new field in the PyModuleDef struct to register the callback. Note that<br>
this change no longer keeps up binary compatibility, which may or may not<br>
be acceptable for Python 3.4.<br></blockquote><div><br>It's not acceptable, as PyModuleDef is part of PEP 384's stable ABI. All such public structures are locked at their original size.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3) The original proposal used a new C-API function to register the callback<br>
explicitly, as opposed to extending the PyModuleDef struct. This has the<br>
advantage of keeping up binary compatibility with existing Py3.3<br>
extensions. It has the disadvantage of adding another indirection to the<br>
setup procedure where a static function pointer would suffice.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br><br>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.<br>
<br></div></div>Cheers,<br>Nick.<br><br>-- <br>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div>