[Python-Dev] test___all__ polluting sys.modules? (original) (raw)

R. David Murray rdmurray at bitdance.com
Sun Dec 30 15:48:30 CET 2012


On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky <eliben at gmail.com> wrote: > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah <stefan at bytereef.org> wrote: >> >> Eli Bendersky <eliben at gmail.com> wrote: >> > Yes, this is the solution currently used in testxmletree. However, >> > once >> > pickling tests are added things stop working. Pickle uses import to >> > import >> > the module a class belongs to, bypassing all such trickery. So if >> > test_all_ >> > got elementtree into sys.modules, pickle's import finds it even if >> > all the >> > tests in testxmletree manage to ignore it for the Python version >> > because they >> > use importfreshmodule. >> >> I ran into the same problem for testdecimal. The only thing that appears >> to work is to set sys.modules['decimal'] explicitly before calling >> dumps()/loads(). See: >> >> PythonAPItests.testpickle() >> ContextAPItests.testpickle() > > Yes, this seems to have done the trick. Thanks for the suggestion.

It may be worth offering a context manager/decorator equivalent to "importfreshmodule".

I suggested making import_fresh_module a context manager in the issue that Eli opened about test___all__.

> I'm still curious about the test-in-clean-env question though.

As Stefan noted, the main advantage we get is that sometimes the failure to clean up properly is in the standard lib code rather than the tests, and with complete isolation we'd be less likely to notice the problem. Once you combine that with the fact that rearchitecting regrtest to work that way would be quite a bit of work, the motivation to make it happen goes way down. However, specifically spinning out the "import the world" tests like testpydoc and test_all to a separate process might be worth the_ effort.

Adding something to regertest (or unittest?) so that certain nominated test modules are run in a subprocess has been discussed previously, but so far no one has stepped up to implement it :) (I think this came up originally for test_site, but I don't remember for sure.)

--David



More information about the Python-Dev mailing list