Brett Cannon <br...@python.org> added the comment: A couple of things about all of this.
One, we should not blindly pull in the PyPy code without some core PyPy developer being in on this; just common courtesy and I don't think anyone participating in this discussion is a PyPy developer (but I could be wrong). Two, as David pointed out, parsing overhead is pretty minor thing to be worrying about thanks to bytecode. The import * solution at the end of the main file is the agreed-upon approach (it has been discussed at some point). Three, for testing you can also look at test_warnings (the creation of _warnings led to the discussion of best practices for all of this). Basically you use test.support.import_fresh_module to get the pure Python version and the C-enhanced one, write your tests with the module being tested set on the class, and then subclass with the proper modules as a class attribute. I understand your worry, Alexander, about accidentally missing a test class for a module, but in practice that will be rare as people will be watching for that, and you just do the subclass first. There is in practice no need to get too fancy, and you have to make sure your tests are discoverable anyway by test runners that simply look for classes that inherit from unittest.TestCase. Best alternative you could do is a metaclass that searches for tests that start with 'test' *and* take an argument for the module to test, and then auto-create methods that take *no* arguments and then call the test methods directly (after renaming them so that test runners don't try to use them). Then you can pass in the modules to test as arguments to the metaclass. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7989> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
