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 <[email protected]>
<http://bugs.python.org/issue13429>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
