[SciPy-Dev] Summarizing the scikit-signal discussion
Fri Jan 13 09:32:11 CST 2012
If I may just give yet another possible justification for a scikit.
Giving the example of scikit-learn, we have a lot of contributors
not working with scipy master including me on my mac laptop.
One reason among other is to avoid a dependency on gfortran
which leaves for example most windows contributors aside.
It's also much easier and less frightening to contribute to a small project.
my 2 cents,
On Fri, Jan 13, 2012 at 4:19 PM, Bruce Southey <firstname.lastname@example.org> wrote:
> On 01/12/2012 02:37 PM, Jaidev Deshpande wrote:
>> Hi list,
>> I have attempted to summarize the recent discussion we had about the
>> idea of creating a scikit for signal processing in this blog post:
>> The purpose of the post is to highlight the key arguments made in our
>> discussions about scipy.signal - it's limitations and scope - and the
>> additional signal processing abilities that we would like to see in
>> I intend this post to be the flag-off for the scikit-signal
>> development. Please let me know if I've missed anything.
>> SciPy-Dev mailing list
> I am curious why you want to jump to a 'scikit' approach especially with
> the usage and power of git.
> 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
More information about the SciPy-Dev