STINNER Victor <vstin...@python.org> added the comment:
> So I'd like to suggest to write import tests on their module test
> by using _testcapi.run_in_subinterp() for each case.
I like this idea. But I would prefer to factorize the code as much as possible.
Like being able to add more checks later without having to modify N files. In
test_xxx, I expect something like:
---
class SubinterpreterTests(support.SubinterpreterTestCase):
module_name = "xxx"
---
Nothing else, all logic would live in a different file, like test.support.
I prefer to use a string for the module. For example, it is possible to import
a fresh copy of the module in the current interpreter using a module name.
We can start with a single test which imports the module in run_in_subinterp(),
but it becomes possible to add more tests later. For example, import in the
current interpreter, import in a subinterpreter, and ensure that the two
modules are not the same object.
I see an advantage of putting such tests in each test_xxx file: it prevents to
have to import 50+ modules in test_interpreters which would increase its memory
footprint, likely have unexpected side effects, etc.
Maybe support.SubinterpreterTestCase should give the ability to override some
method. For example, if we need a fresh copy of a module, maybe we should give
the ability to provide a list of blocked modules. That's important for "io" vs
"_pyio" tests, or "datetime" vs "_datetime", etc. (PEP 399)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40987>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
