[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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4