Stefan Behnel added the comment:

I'm increasing the target version as this didn't change anything for 3.3. 
However, for 3.4, it might be possible to work around this by splitting the 
module init function into two parts, one that gets executed in order to create 
the module object (and do safe C level setup etc.) and one that gets executed 
after properly registering the module and setting __file__ and friends 
externally and that can then populate the module dict etc.

I can see two ways how this can be done. The shared library could optionally 
export a second symbol ("PyInit2_modulename" or whatever), or it could set a 
sort of callback function on the module object it returns in its original init 
function, either in the module dict or using a C level interface. I prefer the 
latter because it's safer - code can't accidentally rely on this feature in 
other Python versions (or implementations) because it would fail to build there 
if the required C-API function isn't available.

A corner case that this wouldn't fix is the creation of more than one module 
object in the module init function, but I think it's a reasonable restriction 
that users should be on their own here and should properly set up these 
additional modules themselves. Alternatively, this could be handled (with some 
overhead) if the import machinery remembered all modules created during the 
execution of the module init function and post-processed them as noted above.

So, my proposal would be to add a new callback function field to module objects 
and a new C-API function "PyModule_SetInitFunction(module, c_func)" that 
registers a C callback function on a module object. Then, extend the shared 
library importing code to call that init function if it's available, passing it 
both the module instance and an extensible context struct in order to enable 
future extensions to this interface.

I realise that this might have to go through a PEP process, but do you see any 
obvious flaws I missed so far or reasons to reject this approach right away?

versions: +Python 3.4 -Python 3.3

Python tracker <>
Python-bugs-list mailing list

Reply via email to