[SciPy-dev] Package organization

[Ed Schofield]

Pearu Peterson wrote:

>If odepack/vode will be under scipy.ode and quadpack under scipy.integrate 
>then couldn't sundials be under scipy.dae? It's more informative for those
>not knowing about sundials but need to solve dae's.
>
>That's also related to my preference of putting wrappers under scipy.lib
>and let higher lever packages such as scipy.ode, scipy.integrate, etc
>to import needed tools from scipy.lib. After all, higher level packages 
>may use different library wrappers for the same task, just using different 
>numerical methods that may be more suitable for a particular problem.
>  
>

+1.  I think users will appreciate a task-oriented over a
wrapper-oriented hierarchy.

>I have learned from the hard way to prefer the modularity already from the 
>maintainence point of view. When tracking down bugs, the modularity gives 
>great advantages. And considering how many scipy packages currently lack 
>even basic unittests, there are lots of bugs to be discovered yet.
>
>And I don't think that some internal modularity of scipy would confuse 
>end users, they would still use only higher level scipy packages that 
>live directly under scipy.
>
>I would sum up the implications of this thread as follows. We should view 
>each scipy package separately. Some of them can be completely standalone 
>(which is always a good property of a package), they contain both toolkits 
>and wrappers to domain specific libraries. But there are also scipy 
>packages that would use the same library wrappers and so such libraries 
>should be made directly available for all such scipy packages. And by 
>directly I mean that one scipy package should not import another scipy 
>package in order to access some particular wrapper library.
>
>So, as a first instance, when developing a scipy package, library wrappers 
>can be placed under this pacticular scipy package. But once the library 
>wrappers could be used by another scipy package, there should be an easy 
>way to move library wrappers under scipy.lib.
>
>Would such a compromise be acceptable?
>  
>

+1