[issue12554] Failed imports clean up module, but not sub modules

Eric Snow added the comment: Yeah, I missed the line where he imported foo.bar in "foo/__init__.py", and thought something else was going on. "foo/__init__.py" does not have to finish importing (just has to be on sys.modules) at the point foo.bar is imported. So foo.bar would be completely

[issue12554] Failed imports clean up module, but not sub modules

R. David Murray added the comment: In fact, to hopefully make perfectly clear what is going on here, let me demonstrate that *any* executable statement in the module that fails to load is executed if it occurs before the error that causes the load failure: rdmurray@hey:~/python/p32>cat te

[issue12554] Failed imports clean up module, but not sub modules

R. David Murray added the comment: Yes, that's exactly my point. The loading of a module into sys.modules is a separate issue from the creation of a pointer to that module in the local name space. Once the former succeeds, it has succeeded and won't be done again. When the module that did

[issue12554] Failed imports clean up module, but not sub modules

Eric Snow added the comment: But it is curious that the submodules were added to sys.modules even though the package failed to import. -- nosy: +ericsnow ___ Python tracker ___

[issue12554] Failed imports clean up module, but not sub modules

R. David Murray added the comment: That can't be done. If an import fails, it fails. But if it succeeds, the module is loaded, and there is no reason to unload it. After all, import in python is idempotent (doing it a second time has no effect other than adding the name to the local namesp

[issue12554] Failed imports clean up module, but not sub modules

New submission from Calvin Spealman : I came across this behavior when it was related to the shadowing of a small typo bug and took me forever to find. In my case, the original error was shadowed in a way that is unrelated to this bug, but lead to the module being imported twice (because it wa