Stefan Behnel added the comment:

Agreed. Since it doesn't really fit into any specific function documentation, I 
would place it right at the top. Something like this:

The following functions can be used by C code to call into Python's import 

Note that Python 3 does not automatically register an extension module in 
sys.modules on creation (see module.html#initializing-c-modules). It is only 
added after running through the whole module init function. This means that a 
request to import the current module while its init function is still running 
(either directly or transitively by other modules) will try to reimport the 
module. If you cannot be sure that this will not happen, you have to register 
the newly created module yourself as follows, using the fully qualified module 

    PyObject *the_module = PyModule_Create(py_module_def);
    if (the_module == NULL) { /* failure ! */ };

    PyObject *sys_modules = PyImport_GetModuleDict();
    if (sys_modules == NULL) { /* failure ! */ };

    if (PyDict_SetItemString(modules, "the.package.and.module", the_module) < 
0) { /* failure ! */ };

Maybe it should add another comment that this is a major quirk in the runtime 
and say "sorry for being stupid here - I hope you can do better". Requiring the 
user to know the FQMN at build time because the import machinery fails to set 
it automatically is just embarrissing.

Then, after the first sentence in the module.html#initializing-c-modules 
section, I'd add this:

Note that, starting with Python 3.0, the module creation functions no longer 
register the module in sys.modules. The import machinery will only do this 
after the module init function has run. If you need to run imports as part of 
your module init function and happen to know the fully qualified module name in 
your code, it is best to register the module yourself after creating it.

I wonder if the code example shouldn't go on the "module" page.


Python tracker <>
Python-bugs-list mailing list

Reply via email to