[Python-Dev] Fix import errors to have data
Tim Peters
tim.peters at gmail.com
Sun Aug 1 18:41:32 CEST 2004
[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?
More information about the Python-Dev
mailing list