[SciPy-dev] Package organization

Pearu Peterson pearu at scipy.org
Thu Oct 13 01:26:56 CDT 2005

On Thu, 13 Oct 2005, Fernando Perez wrote:

> Robert Kern wrote:
>> I would like to see scipy's package organization become flatter and more
>> oriented towards easy, lightweight, modular packaging rather than
>> subject matter. For example, some people want bindings to SUNDIALS for
>> ODEs. They could go into scipy.integrate, but that introduces a large,
>> needless dependency for those who just want to compute integrals. So I
>> would suggest that SUNDIALS bindings would be in their own
>> scipy.sundials package.

This is for what scipy.lib namespace was created, to collect packages 
containing wrappers to various libraries. So, how
sounds for you in addition to
   etc etc

Among other things this may reduce the time spent on importing large 
extension modules that users might not use in their programs.

> [snip excellent analysis of scipy's organizational status ]
> Let me add a minor twist to your plan, which perhaps may help a little.  How
> about making a two-level distinction between 'scipy, the core package' and
> 'scipy, the collection of tools'?  Here's how it could be organized, in terms
> of namespaces and release policy: whatever is defined as the core is released
> by the scipy package proper, and can be safely considered a dependency for the
> rest.  Note that this can still be split between scipy_core and 'full scipy',
> where scipy_core is Travis' new Numeric/numarray and 'full scipy' contains
> much more functionality.
> But as far as packages written by third-party authors, which can live under
> the scipy namespace as an umbrella, benefit from scipy's build facilities and
> core libraries, how about putting them all into a 'toolkits' namespace?  The
> actual name, for typing convenience, could be scipy.kits or scipy.tools
> (something short).
> This would then give us the following structure:
> 1.  Scipy_core: the new Numeric/numarray package, which includes basic FFT,
> linear algebra, random numbers and perhaps basic i/o (at least save/load
> abilities), and whatever else I'm missing right now (I don't have it yet
> installed on this laptop).
> 2.  Scipy 'full': depends on (1), and exposes all the other scipy names:
> scipy.{linalg,optimize,integrate,...}.  These are libraries considered
> officially part of scipy, so that even if they are maintained by others (much
> like python's stdlib), there is a committment to a common release cycle.
> These can, if need be, have inter-dependencies, as they will always be
> released as a whole.

This is pretty much the current structure of newcore and newscipy, even of 
old scipy and scipy_core.

> 1 and 2 all use the top-level scipy namespace.  Then we have:
> 3.  The scipy.{kits|tools} namespace (or whatever the chosen name).  This is
> where third parties can drop their own packages, which can depend either only
> (1) or on the full (2) system (their level of dependency should be explicitly
> stated).

Ok, that's a new bit, though it remainds me the scipy.sandbox package in 
newscipy. May be it's a matter of naming convention.


More information about the Scipy-dev mailing list