On Sat Jul 28 10:54:24 CEST 2012, Serhiy Storchaka storchaka at gmail.com wrote:

For not to duplicate the supporting code, I suggest add (move from test_sys test) three utility functions to test.support module (issue #15467). Also from the use of the common code will benefit issues #15402 (for struct) and #15424 (for array). The testing for cElemetTree also will be easier.

Martin remarked that this adds new features to test.support and can only be done in 3.4. Question to release managers. Whether this is acceptable, if we do these functions private (with names that begin with an underscore)? Or would we have to copy the supporting code in every test file with __sizeof__ test?

This is nearly the same as the question I asked below about feature freeze (or that I was trying to ask), to which I thought I received an answer different from the one stated above: "(2) When adding new tests (e.g. in the course of fixing a bug or increasing test coverage), are we allowed to refactor other tests so that supporting test code can be shared? Or should the tests be added in a less DRY fashion and refactored only after the branch goes back to pre-alpha?" http://mail.python.org/pipermail/python-dev/2012-July/121137.html I don't feel test.support should be held to the same standard as the public modules based in part on the documentation note below: "Note: test.support is not a public module. It is documented here to help Python developers write tests. The API of this module is subject to change without backwards compatibility concerns between releases." http://docs.python.org/dev/library/test.html#module-test.support I think it benefits us to have a test support API that we can change at any time. This lets us improve the quality and maintainability of our tests (e.g. by making them more DRY) with fewer obstacles. Otherwise, we are creating barriers for ourselves to increasing code coverage of the code that we really want to keep unchanged. --Chris