[pypy-dev] certificate for accepting numpypy new funcs?

[Maciej Fijalkowski]

On Thu, Jan 19, 2012 at 6:46 PM, Dmitrey <dmitrey15 at ukr.net> wrote:
> Hi all,
> could you provide clarification to numpypy new funcs accepting (not only for
> me, but for any other possible volunteers)?
> The doc I've been directed says only "You have to test exhaustively your
> module", while I would like to know more explicit rules.
> For example, "at least 3 tests per func" (however, I guess for funcs of
> different complexity and variability number of tests also should expected to
> be different).
> Also, are there any strict rules for the testcases to be submitted, or I,
> for example, can mere write
>
> if __name__ == '__main__':
>    assert array_equal(1, 1)
>    assert array_equal([1, 2], [1, 2])
>    assert array_equal(N.array([1, 2]), N.array([1, 2]))
>    assert array_equal([1, 2], N.array([1, 2]))
>    assert array_equal([1, 2], [1, 2, 3]) is False
>    print('passed')

We have pretty exhaustive automated testing suites. Look for example
in pypy/module/micronumpy/test directory for the test file style.
They're run with py.test and we require at the very least full code
coverage (every line has to be executed, there are tools to check,
like coverage). Also passing "unusual" input, like sys.maxint  etc. is
usually recommended. With your example, you would check if it works
for say views and multidimensional arrays. Also "is False" is not
considered good style.

>
> Or there is a certain rule for storing files with tests?
>
> If I or someone else will submit a func with some tests like in the example
> above, will you put the func and tests in the proper files by yourself? I'm
> not lazy to go for it by myself, but I mere no merged enough into numpypy
> dev process, including mercurial branches and numpypy files structure, and
> can spend only quite limited time for diving into it in nearest future.

We generally require people to put their own tests as they go with the
code (in appropriate places) because you also should not break
anything. The usefullness of a patch that has to be sliced and diced
and put into places is very limited and for straightforward
mostly-copied code, like array_equal, plain useless, since it's almost
as much work to just do it.

>
> Of course, you can provide very strict rules of funcs and related testcases
> submission for to improve quality, but I guess it can reduce number and
> willing of volunteers to assist, hence an appropriate middle should be
> chosen.
>
> BTW, the ndarray.flat bug mentioned in https://bugs.pypy.org/issue1009 still
> prevents contribution of funcs diag, eye, array_equal and many others.

Yes, flatiter is unfortunately in a sad state. There is however a
branch to fix it and people working on it.