[SciPy-dev] More bugs fixed

[Arnd Baecker]

On Fri, 7 Oct 2005, Travis Oliphant wrote:

> Stephen Walton wrote:
>
> >Fernando Perez wrote:
> >
> >>Just to clarify (sorry, but I'm a bit dizzy from the current naming blizzard):
> >>for those of us who install/use the full scipy, scipy.{fft,linalg,random,...}
> >>would continue to exist, correct?  Or would they instead be found as
> >>scipy.lib.{fft,...}?
> >>
> >I would vote for them still being found as scipy.{fft,linalg,...}.  To

+1 (FWIW)

> >me, scipy.lib.something implies that all that's there is a library, not
> >a set of tools for doing "something."  I personally think the primary
> >goal here is to have basic stable tools which are always there, so that
> >someone developing a third party package for scipy can depend on them.
> >
> Right now all the extra's beyond the basic arrayobject, it's functions,
> and the ufunc object
>
> are in a package called
>
> scipy.basic
>
> There you can find modules
>
> scipy.basic.fft
> scipy.basic.linalg
> scipy.basic.random
>
> that contain the functionality  (often by importing some heavy-lifting
> code from scipy.lib.<something>
>
> Full scipy will still have
>
> scipy.fftpack
> scipy.linalg
> scipy.stats
>
> as it does now.

Question: wouldn't it be possible to use
`scipy.linalg` both for "scipy core" and for "scipy full"?

When only "scipy core" is installed,
scipy.linalg will just contain the basic routines,
and use lapack_lite (and possibly no dotblas etc.).

When also "scipy full" is installed, scipy.linalg will
have the full glory of all the routines provided in present scipy.

Technically the question is if there is
a way to achieve this without "scipy full" overwriting
files from "scipy core" (thinking of .deb/.rpm/... packages).

Does this sound reasonable and feasible?

Best, Arnd