[Tim]
... I guess that any path thru import.c calling PyImport_AddModule() before calling PyImport_ExecCodeModuleEx() will suffer similarly (because the former convinces the latter then that the module "is pre-existing", even if it really wasn't, and the latter won't remove it from sys.modules then despite that running its code fails).
And I posted a patch later that "fixed this" in one case involving packages. I don't know much about import details, but I believe there are other cases -- just search for PyImport_AddModule. Some look harmless, but some don't:
- PyImport_ImportFrozenModule. In case of a package, creates a module object first to set its __path__, before running the code.
- zipimporter_load_module (in zipimport.c). Similarly, but also sets __loader__ before running the code, package or not.
- Py_InitModule4 (in modsupport.c) leaves a damaged module behind if initialization fails.
"A problem" is that PyImport_ExecCodeModuleEx seems to be the only real choke point, and is making a distinction between "old" and "new" modules that doesn't always match its callers' realities. This distinction came from here:
[Guido]
What should it do if the module already existed (e.g. when used by reload())? Strawman answer: leave it there -- the reload() semantics and common use cases are best served by that.
I understand the point there for reload(), but don't know of other use cases (let alone common ones <wink>) for wanting to leave a module in sys.modules when its code fails. What are they? Maybe it would be better for PyImport_ExecCodeModuleEx to purge a broken module unconditionally, and change PyImport_ReloadModule to put it back?