[Python-Dev] Fix import errors to have data

[Tim Peters]

[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?