[Python-Dev] Allowing to run certain regression tests in subprocesses (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Aug 4 04:08:13 CEST 2013

On 4 Aug 2013 12:03, "Eli Bendersky" <eliben at gmail.com> wrote:

On Sat, Aug 3, 2013 at 6:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > > On 4 Aug 2013 09:43, "Eli Bendersky" <eliben at gmail.com> wrote: >> >> Hi All, >> >> Today the issue of cross-test global env dependencies showed its ugly >> head again for me. I recall a previous discussion >> (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) >> but there were many more over the years. >> >> The core problem is that some tests modify the global env >> (particularly importing modules) and this sometimes has adverse >> effects on other tests, because test.regrtest runs all tests in a >> single process. In the discussion linked above, the particular culprit >> test_all was judged as a candidate to be moved to a subprocess._ >> >> I want to propose adding a capability to our test harness to run >> specific tests in subprocesses. Each test will have some simple way of >> asking to be run in a subprocess, and regrtest will concur (even when >> running -j1). test_all can go there, and it can help solve other_ >> problems. >> >> My particular case is trying to write a test for >> http://bugs.python.org/issue14988 - wherein I have to simulate a >> situation of non-existent pyexpat. It's not hard to write a test for >> it, but when run in tandem with other tests (where C extensions loaded >> pyexpat) it becomes seemingly impossible to set up. This should not be >> the case - there's nothing wrong with wanting to simulate this case, >> and there's nothing wrong in Python and the stdlib - it's purely an >> artifact of the way our regression suite works. > > I'm not actively opposed to the suggested idea, but is there a specific > reason "test.support.importfreshmodule" doesn't work for this test? I'm not an expert on this topic, but I believe there's a problem unloading code that was loaded by C extensions. importfreshmodule is thus powerless here (which also appears to be the case empirically).

Sure, it's just unusual to have a case where "importing is blocked by adding None to sys.modules" differs from "not actually available", so I'd like to understand the situation better.

Cheers, Nick.

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130804/9c0ac464/attachment.html>

More information about the Python-Dev mailing list