As part of PEP 399, an idiom for testing both C and pure Python versions of a library is suggested making use if import_fresh_module.

Unfortunately, I'm finding that this is not amazingly robust. We have this issue: https://bugs.python.org/issue40058, where the tester for datetime needs to do some funky manipulations to the state of sys.modules for reasons that are now somewhat unclear, and still sys.modules is apparently left in a bad state.

When implementing PEP 615, I ran into similar issues and found it very difficult to get two independent instances of the same module – one with the C extension blocked and one with it intact. I ended up manually importing the C and Python extensions and grafting them onto two "fresh" imports with nothing blocked.

This seems to work most of the time in my repo, but when I import it into CPython, I'm now seeing failures due to this issue. The immediate symptom is that assertRaises is seeing a mismatch between the exception raised by the module and the exception *on* the module. Here's the Travis error (ignore the part about `tzdata`, that needs to be removed as misleading), and here's the test. Evidently calling module.ZoneInfo("Bad_Zone") is raising a different module's ZoneInfoNotFoundError in some cases and I have no idea why.

Is anyone familiar more familiar with the import system willing to take a look at these issues?

Thanks,
Paul