On Tue, 27 Jul 2004 12:39:22 -0400
Jim Fulton
Tim Peters wrote:
[Jim Fulton] ...
No, it won't. For example, suppose foo imports B. B tries to import C, but fails. B is now broken, but it is still importable. Actually,>both foo and B can be imported without errors, even though they are>broken.
Then you're proposing a way for a highly knowledgable user to anticipate, and partially worm around, that Python leaves behind insane module objects in sys.modules.
No. I'm proposing a way for a Python developer to detect the presence or absence of a module.
Hm, perhaps it would be better to provide an API (if there isn't one already) to test whether a module is present.
If such an api were to exist, what question exactly would it answer? 1. That there is a module by a particular name that could possibly be imported, but the import may not succeed when actually tried. 2. There is a module by a particular name which can be imported and the import will not fail. I would vote for the former, but it might be surprising to run into behavior like this:
sys.hasmodule('foo') True import foo ImportError: foo blew
What if there was a new exception ModuleNotFoundError which subclassed ImportError. This would be raised by the import machinery when the module could not be found. Errors during import would continue to raise a standard ImportError. I think this, coupled with Jim's original suggestion and Tim's to prevent broken modules being retained in os.modules would help a lot. -Casey