On Wed, May 6, 2020 at 7:52 AM Paul Ganssle <p...@ganssle.io> wrote: > > 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.
When I've had to deal with similar issues in the past, I've given up on messing with sys.modules and just had one test spawn a subprocess to do the import+run the actual tests. It's a big hammer, but the nice thing about big hammers is that there's no subtle issues, either they smash the thing or they don't. But, I don't know how awkward that would be to fit into Python's unittest system, if you have lots of tests you need to run this way. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SDSODK5ZSJUSGDFVFOAESHYLPPFANNWD/ Code of Conduct: http://python.org/psf/codeofconduct/
