[SciPy-dev] The future of SciPy and its development infrastructure
Travis E. Oliphant
Wed Feb 25 14:33:25 CST 2009
Stéfan van der Walt wrote:
> Hi Matthew
> 2009/2/24 Matthew Brett <firstname.lastname@example.org>:
>> I think Stefan's position is that, as more people start using and
>> contributing to Scipy, it's become near impossible to maintain in a
>> release-worthy way (Stefan - is that right)? That if we want to
>> keep going without collapsing we need a more formal process.
> Exactly. If we keep introducing new bugs ourselves, there's not
> enough time in the world to bring SciPy up to standard.
When have you done enough "testing" or "documentation"? We need
bright, dedicated people working on SciPy and using good judgment.
Sometimes that means emphasizing tests. Sometimes that means
emphasizing documentation. Sometimes it means thinking hard about the
algorithm you are implementing and carefully coding it.
Unit-testing is a tool, but it requires more than that to create code
that others can use and rely on --- a skill I don't think we can
quantify sufficiently to formalize a process that by itself "produces
> With the nose framework in place, writing tests is so very easy:
> def test_myfoo():
> assert 1 == 1
> So I hope that everyone would agree that proper testing and
> documentation improves life, not only for the user community, but also
> for the contributor.
Yes, unit-testing is essential when you need to re-factor --- but it
comes with a cost. Code that is unit-tested requires those tests to
also be re-factored when the code gets refactored, so there is such a
thing as "unit-testing an API too early". Thus, there is a life-cycle
question for unit-test coverage. Early-on fewer core unit-tests are
appropriate. Later, when the API is stabilized, more unit-tests are
appropriate. I can't give hard numbers for what is "right" or when
the transition is made.
More information about the Scipy-dev