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?