[SciPy-Dev] Summarizing the scikit-signal discussion

[Bruce Southey]

On 01/13/2012 09:34 AM, Robin wrote:
> On Fri, Jan 13, 2012 at 4:19 PM, Bruce Southey<bsouthey at gmail.com>  wrote:
>> I am curious why you want to jump to a 'scikit' approach especially with
>> the usage and power of git.
> I think some points that were mentioned previously about the advantage
> of a seperate scikit is that allows a faster release cycle for getting
> binary installers to end users (not tied to slower scipy releases) and
> that it allows more exploratory API development (without being tied to
> conservative scipy deprecation policy).
>
> Cheers
>
> Robin
>
>> If the goal is to improve and extend parts of scipy, then a scikit is
>> only useful for code that has a different license than scipy. It would
>> be more effective to just create a new git branch. That way changes can
>> be easily integrated back into scipy as well as maintaining the changes
>> in numpy/scipy. More importantly, other scipy-dependent projects can
>> move and replace relevant code (assuming appropriate licensing) into
>> that branch thus avoiding any new dependencies in those projects.
>>
>> Thus, just branch scipy, add your code (including tests and
>> documentation) and provide guidance/leadership on how different pieces
>> that people contribute can be incorporated.
>>
>> Bruce
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
I was working on the assumption from the emails and blog that the goal 
was to improve scipy so everything must come back into scipy.  If that 
is incorrect then ignore what I have said and what is below.

I do not see that any of the arguments apply because those incorrectly 
assume that you are tied scipy by branching as you can easily create a 
binary from a branch. It may be advantageous for those binary-only users 
to have the same scipy version all in a single binary file especially if 
scipy changes after branching.

You have to be constrained by API changes when the changes of *existing* 
functions incorporated back into scipy. Although scipy's API changes are 
still somewhat more flexible than numpy's because it is still considered 
'beta'. Also these constraints could be easily removed by having new 
function names that replace existing functions.

Currently the Fortran-dependency occurs because parts of scipy.signal 
directly Fortran (some functions import scipy.linalg and 
scipy.interpolate). So to remove Fortran, all those Fortran-dependencies 
will have to go and those changes would also have to be pushed back to 
scipy for any future merging.

Bruce