[SciPy-Dev] Summarizing the scikit-signal discussion
Fri Jan 13 11:38:57 CST 2012
On 01/13/2012 09:34 AM, Robin wrote:
> On Fri, Jan 13, 2012 at 4:19 PM, Bruce Southey<email@example.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).
>> 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.
>> SciPy-Dev mailing list
> SciPy-Dev mailing list
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.
More information about the SciPy-Dev