[SciPy-dev] The future of SciPy and its development infrastructure

[Travis E. Oliphant]

Stéfan van der Walt wrote:
> Hi Matthew
>
> 2009/2/24 Matthew Brett <matthew.brett at gmail.com>:
>   
>> 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 
more contributions"


> 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.

-Travis