gh-157384: Refuse inittab names in PyImport_CreateModuleFromInitfunc()

[itamaro]

Modules created by PyImport_CreateModuleFromInitfunc() share the extensions cache and sys.modules with built-in modules. Passing a spec whose name is registered in PyImport_Inittab either silently ignored the init function (for an already loaded single-phase builtin, or for "sys" and "builtins") or replaced the built-in module in sys.modules (for a multi-phase builtin). Raise ImportError instead.

AI assisted with Claude Fable 5.1

• Issue: PyImport_CreateModuleFromInitfunc(): wrong __name__ for submodules, non-ASCII names rejected, inittab name clashes #157384

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #34530618 | 📁 Comparing a0de16a against main (2cd6d4b)

  🔍 Preview build  

2 files changed

± c-api/import.html
± whatsnew/changelog.html

[encukou]

Looking at your post (and not checking the code in detail): at least for multi-phase modules, this looks like it's is working as expected. For multi-phase case, sys.modules shouldn't be involved; you're free to create any module object you wish. (Replacing existing sys.modules entries would be questionable of course, but, that's not in scope for PyImport_CreateModuleFromInitfunc.)

For single-phase, things are less clear, but I think the documented quirk applies: “For subsequent imports, Python does not call the initialization function again.”
We should be clearer about what the lookup key for “subsequent imports”, but, I don't think this needs a behaviour change. (as in: I don't know off the top of my head if you get a new module or the cached one, but either is fine; we should probably document what happens.)

Bottom line, I thing scanning inittab is the users' responsibility.

[itamaro]

I agree with you, I think this PR can be closed, I'd fold the docs clarification into gh-157389