On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah <stefan@bytereef.org> wrote:
">

(original) (raw)




On Sun, Dec 30, 2012 at 6:06 AM, Eli Bendersky <eliben@gmail.com> wrote:



On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah <stefan@bytereef.org> wrote:
Eli Bendersky <eliben@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()


test\_decimal ruthlessly switches sys.modules\['decimal'\] many times. At the
end of all tests there is a sanity check that asserts that the number of
changes were in fact balanced.

Thank you, I'll try this. I'm also experimenting with other approaches.

By the way, from clean default checkout:

$ ./python -mtest test\_\_\_all\_\_ test\_int

[1/2] test___all__
[2/2] test_int
test test_int failed -- Traceback (most recent call last):
� File "/home/eliben/python-src/default/Lib/test/test_int.py", line 236, in test_keyword_args
��� self.assertRaises(TypeError, int, base=10)

AssertionError: TypeError not raised by int

1 test OK.
1 test failed:
��� test_int

Should this really fail? [I haven't investigated the root cause yet]


This is a false alarm, sorry. Please ignore this report (I had some stale build artifacts).

Eli