[Python-Dev] test___all__ polluting sys.modules?

[Eli Bendersky]

On Mon, Dec 31, 2012 at 7:30 PM, Gregory P. Smith <greg at krypto.org> wrote:

>
> On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray <rdmurray at bitdance.com>wrote:
>
>> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130101/aa3fd0dd/attachment.html>