[Python-Dev] Fix import errors to have data (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Aug 3 05:22:04 CEST 2004

At 11:14 PM 8/2/04 -0400, Tim Peters wrote:

[Christian Tismer] .. > Yes, but I think you are almost an atom's distance apart off of > the final solution. Grab it!

If you mean this: >>> Maybe it could be as simple as saving a snapshot of >>> sys.modules whenever importing of a module is begun, >>> and if execution of its body doesn't complete, restoring >>> the snapshot? then no, that's a long way off in CPython. There's no choke point for when importing begins, or for when importing ends, and even builtin.import is routinely replaced. Guido latched on to the only choke point there is: sooner or later, every import gimmick worthy of the name has to execute "the module's" code, whether it be direct import from Python, directly via C API calls, implicit package init.py imports, imports arranged via magical importers (like the .zip importer), etc. So that's what the patch targeted: there's one routine that executes a module's initialization code, all imports go thru it eventually, and that's the routine that now removes the module's name from sys.modules if the initialization code barfs.

It's worse than that... 'ihooks' and 'imputil', for example, both do:

 exec code in module.__dict__

so they'd need to be changed to support this fix as well. (Not to mention any third-party import hooks...)

More information about the Python-Dev mailing list