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

<p dir="ltr">Cheers,<br>
Nick.<br>
><br>
> Eli<br>
</p>