[SciPy-Dev] Proposal for Scikit-Signal - a SciPy toolbox for signal processing
Wed Jan 4 08:53:45 CST 2012
On Wed, Jan 4, 2012 at 9:30 AM, Skipper Seabold <firstname.lastname@example.org> wrote:
> On Wed, Jan 4, 2012 at 1:37 AM, Travis Oliphant <email@example.com> wrote:
>> So, my (off the top of my head) take on what should be core scipy is:
>> I think the other packages should be maintained, built and distributed as
>> scipy-weave (actually I think weave should be installed separately and/or merged with other foreign code integration tools like fwrap, f2py, etc.)
>> Then, we could create a scipy superpack to install it all together. What issues do people see with a plan like this?
> My first thought is that what is 'core' could use a little more
> discussion. We are using parts of integrate and signal in statsmodels
> so our dependencies almost double if these are split off as a separate
> installation. I'd suspect others might feel the same. This isn't a
> deal breaker though, and I like the idea of being more modular,
> depending on how it's implemented and how easy it is for users to grab
> and install different parts.
I think that breaking up scipy just gives us a lot more installation
problems, and if it's merged together again into a superpack, then it
wouldn't change a whole lot, but increase the work of the release
I wouldn't mind if weave is split out, since it crashes and I never use it.
The splitup is also difficult because of interdependencies,
stats is a final usage sub package and doesn't need to be in the core,
it's not used by any other part, AFAIK
it uses at least also integrate.
optimize uses sparse is at least one other case I know.
I've been in favor of cleaning up imports for a long time, but
splitting up scipy means we can only rely on a smaller set of
functions without increasing the number of packages that need to be
What if stats wants to use spatial or signal?
> SciPy-Dev mailing list
More information about the SciPy-Dev