Perhaps that is a concrete thing that I can do over the next few months: Follow-up with different developers of packages that might be interested in incorporating their code into ScIPy as a module or as part of another module. Longer term, I would like to figure out how to make SciPy more modular. -Travis On Jan 3, 2012, at 2:37 PM, Ralf Gommers wrote:
On Tue, Jan 3, 2012 at 9:18 PM, David Cournapeau <cournape@gmail.com> wrote: On Tue, Jan 3, 2012 at 9:00 AM, Travis Oliphant <travis@continuum.io> wrote:
I don't know if this has already been discussed or not. But, I really don't understand the reasoning behind "yet-another-project" for signal processing. That is the whole-point of the signal sub-project under the scipy namespace. Why not just develop there? Github access is easy to grant.
I must admit, I've never been a fan of the scikits namespace. I would prefer that we just stick with the scipy namespace and work on making scipy more modular and easy to distribute as separate modules in the first place. If you don't want to do that, then just pick a top-level name and use it.
As mentioned by other, there are multiple reasons why one may not want to put something in scipy. I would note that putting something in scikits today means it cannot be integrated into scipy later. But putting things in scipy has (implicitly at least) much stronger requirements around API stability than a scikit, and a much slower release process (I think on average, we made one release year).
Integrating code into scipy after initially developing it as a separate package is something that is not really happening right now though. In cases like scikits.image/learn/statsmodels, which are active, growing projects, that of course doesn't make sense, but for packages that are stable and see little active development it should happen more imho.
Example 1: numerical differentiation. Algopy and numdifftools are two mature packages that are general enough that it would make sense to integrate them. Especially algopy has quite good docs. Not much active development, and the respective authors would be in favor, see http://projects.scipy.org/scipy/ticket/1510.
Example 2: pywavelets. Nice complete package with good docs, much better than scipy.signal.wavelets. Very little development activity for the package, and wavelets are of interest for a wide variety of applications. Would have helped with the recent peak finding additions by Jacob Silterra for example. (Not sure how the author of pywavelets would feel about this, it's just an example).
I'm sure it's not difficult to find more examples. Scipy is getting released more frequently now than before, and I hope we can keep it that way. Perhaps there are simple reasons that integrating code doesn't happen, like lack of time of the main developer. But on the other hand, maybe we as scipy developers aren't as welcoming as we should be, or should just go and ask developers how they would feel about incorporating their mature code?
Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev