[pypy-issue] [issue1008] numpypy: commit the code for empty_like, zeros_like, ones_like

Dmitrey tracker at bugs.pypy.org
Thu Jan 19 09:25:50 CET 2012

Dmitrey <dmitrey15 at ukr.net> added the comment:

As for App vs interp level: I think currently numpypy should focus on
functionality (this is what it lacks), not speed (of course, I don't mean
something like committing O(n**2) algorithms where CPython numpy has O(n log
n)). Thus easier approach should be preferred (App level), when someone will
have better implementation, related commit always can be done.

As for mirroring numpy layout - I don't think exact mirroring will be a good
idea. In CPython numpy some funcs dwell in C code, some in CPython and some in
Python code, that's why that layout is so damned complicated (and is changed
from time to time, e.g. when some funcs are rewritten from C to Cython or Python
or vise versa). We'd better create our own layer0 (e.g. class ndarray), layer1,
layer2 etc.

As for TDD: I think rules of contribution have to be explicitly written
somewhere, for example, "no less that 2 tests per function". As you probably
have seen, I had created some tests for these funcs in the bottom of the url I
provided. In the explicit rules of contribution can be present strict format of
tests as well. But on the other hand, all those nuts spinning will essentially
reduce willing of volunteers (especially newcomers) to contribute. BTW, it's not
necessary for a code contributor to be contributor of tests for the func,
moreover, sometimes it's even better to use other person for this, because
former could live in his own world of delusions, e.g. forget that arrays with
dimension > 3 exist, and having 2nd (or just other) person involved increases
chances of revealing the bug. 

Overall you've mentioned numpypy is running mostly by enthusiasm, but for
creating quality code things cannot always be like that, someone has to do the
boring work with test coverage, improving docstrings etc (BTW AFAIK it's quite
usual for a project from early rapid studies of development by enthusiasm
migrate into slow studies of mostly bugfixes). I think for the particular case
best solution would be sharing a small fee for writing tests for recently
committed funcs (you can propose it on freelancer sites, I could be interested
in it as well) and other boring yet important work like that.

PyPy bug tracker <tracker at bugs.pypy.org>

More information about the pypy-issue mailing list