On Mon, Dec 31, 2012 at 7:30 PM, Gregory P. Smith <g...@krypto.org> wrote:
> > On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray <rdmur...@bitdance.com>wrote: > >> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan <ncogh...@gmail.com> >> wrote: >> > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky <eli...@gmail.com> >> wrote: >> > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah <ste...@bytereef.org> >> wrote: >> > >> >> > >> Eli Bendersky <eli...@gmail.com> wrote: >> > >> > Yes, this is the solution currently used in test_xml_etree. >> 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 test_xml_etree manage to ignore it for the Python version >> > >> > because they >> > >> > use import_fresh_module. >> > >> >> > >> I ran into the same problem for test_decimal. The only thing that >> appears >> > >> to work is to set sys.modules['decimal'] explicitly before calling >> > >> dumps()/loads(). See: >> > >> >> > >> PythonAPItests.test_pickle() >> > >> ContextAPItests.test_pickle() >> > > >> > > Yes, this seems to have done the trick. Thanks for the suggestion. >> > >> > It may be worth offering a context manager/decorator equivalent to >> > "import_fresh_module". >> >> 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 >> > test_pydoc 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.) >> > > test_subprocess and possibly a few others (things testing signal behavior, > etc) already have some individual tests that do this. its pretty easy. > subprocess.Popen of sys.executable typically with -E and the code either > in a string via -c or else point at a second file or add an argument for > main in the current file to detect. making this simpler via something in > test.support might make sense if there is a common need for it. > > Thanks, and I agree that some tests have to be run separately. The patches submitted by Arfrever to http://bugs.python.org/issue1674555 seem interesting and relevant (pulling test_site into a separate process/interpreter). I'll take a look at them once I have some time. Eli
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com