Clearing the ImportErrors a big problem for me because it changes the way python handles a missing module. Normally ImportErrors would be propagated up through the chain of imports. This means that I am not able to fall back to an alternative module if import raised an ImportError. Instead I have to check if the contents of the module is what I expect after loading it.

When import fails(with an ImportError), it still returns a module object, but its empty.

In the application I'm working on we allow users to define plugins by creating a module and putting it in plugins folder. We then scan the folder for plugins on runtime to determine located installed plugins. Since all ImportErrors (from regular python plugins) does not appear, I cannot give the user a proper error message when import failed. Instead I have to just write "no plugins found" when the issue was actually a mistyped import.

Maybe the exception should be saved and re-added later if it was also not a CLR module?

@rmadsen-ks see a pending pull request for this:

#298

@denfromufa, my issue is not that the error is not detailed enough, but that ImportErrors are ignored. Since ImportHook is overridden by pythonnet, this changes the way all python modules are imported not just CLR ones.

@denfromufa, it seemed the issue was caused by me having a DLL with the same name as a python module. In normal cases, the ImportError would be emitted, but not if there is an already loaded assembly with the same name.

It seems a bit probematic because there is a good chance that someone would write a wrapper DLL with the same name as a python dll to call into python with. Not sure if different issue though.

I also had problems with this hook. I think it the long run we should replace it by an entry to sys.meta_path, that should stop it from interfering with the import mechanism.

Since the import hook is gone now, this should be fixed.