[Python-Dev] __sizeof__ tests

[Chris Jerdonek]

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