At 11:22 AM +0200 5/21/99, firstname.lastname@example.org wrote:
find_module() should then first check sys.builtin_module_names with the full name before doing anything else. (probably only when it is confirmed that "foo" is a package.)
All that would be doable, but the real problem is the name of the init function!
Right, I was being naive: I thought that was just "a" problem...
Only one module can define a global symbol "initbar". So the one for foo.bar would have to be called "initfoo.bar" (or something similar). On the other hand, when the same module is used dynamically, the init function must be called "initbar" again (unless the current import mechanism is changed).
So there are really two options:
1) Define a switch that C extensions can check to determine whether the init func should be called initbar or initfoo_bar (or something). This means it's up to the extension developer to cater for statically linked builtin submodules by doing something like this in the extension source:
#ifdef PY_STATIC_SUBMODULES #define initbar initfoo_bar #endif
2) change the DL import mechanism so the init function *has* to be called initfoo_bar. But then, to remain backwards compatible you'd still have use a switch, so it doesn't help much now.