[SciPy-dev] More bugs fixed

[Travis Oliphant]

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 
>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. 

And now installing newcore is more compatible with all of scipy.  
There's just the matter of the __init__ file.

But, frankly, we can probably distribute an __init__ file with scipy 
core that is generic enough to get all the packages installed, and not 
distribute an __init__ file with scipy.

That way we achieve the modularity of scipy that is desired (and can 
perhaps start to persuade people like pysparse to get their package in a 
condition to work like scipy.sparse).  And they can still keep their own 
release (because scipy core will be the basic foundation).

And installing packages separately becomes no big deal at all.

-Travis









>This may not be the case for the rest of scipy.
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>