SyntaxErrors in the target module will rise normally, while SyntaxErrors in dependencies will be added to badmodules. This includes a new regression test.

This fixes an issue where a "fromlist" import with the same name as a previously failed import would be incorrectly added to badmodules. This includes a new regression test.

Bound empty lists have been replaced with the "if param is None" idiom.

Constants imported from imp have been moved to private module-level constants, and ModuleFinder.find_module has been refactored to use importlib. Other than an improvement on how frozen builtin imports are reported (as the frozen imports they are, rather than the stdlib modules they *may* have originated from), these changes maintain complete compatibility with past versions... including odd behavior for returning relative (below current directory, but not a C extension) vs. absolute (above current directory, or a C extension) paths.

Whoops.

Specifically, when checking whether the returned path should be relative or absolute.

Whoops.

Hopefully, this will help the failing tests on Windows.

importlib.util.find_spec(fullname, parent), where fullname contains a dot, results in the parent module being imported. This fix ensures that children are correctly located while also avoiding import side-effects by temporarily clearing sys.modules and modifying sys.path. Now, neither a dotted name nor parent are required.

I have a hunch the failing tests are due to a race condition in how sys.path updates. Sleep a bit here to see.

More test are passing, which supports my theory.

*crosses fingers*

I guess that wasn't the issue...

This will be replaced with several more specific entries detailing the various bug fixes.

Perhaps there is some underlying reference issue with straight-up sys.path replacement. Once again, fingers crossed!

Perhaps test threads are stomping on each others' sys.path?

These are processes, after all...

This is a longshot, but it's pretty much all I have left in terms of ideas.

Is it a refleak issue?

I've also added helpful documentation outlining the reasoning behind various design decisions.

Identity checking is sufficient here.

This is more robust than using a string comparison with "__init__".

This isn't actually needed (or wanted) here.

This is probably a better idea than using the extension alone.

Interestingly, it looks like PathFinder does this for us! That's great, because it really cleans up this section a lot.

Hopefully we can get a tiny boost here by checking likely outcomes first.

This makes the unintuitive reasoning behind this call explicit.