[SciPy-dev] Renaming scipy_core ???

Fernando Perez Fernando.Perez at colorado.edu
Sun Jan 1 14:31:13 CST 2006

Hi all,

> I would go for ndarray so I could use nd as the short version, but sciarray
> or scicore would also suit. I think numpy has too strong a connection to
> numeric. Where does the nd in ndarray come from, anyway?

I think the 'nd' is short for n-dimensional, to emphasize that it's more than 
a simple array (1-d) or matrix (2-d) library.

Here's a suggestion.  I'll use 'scicore' and 'ndarray' as working names, but 
the words can be changed.  What I want to emphasize here is the organizational 
structure, not the actual names.

How about the package being called scicore, which would include the modules:






   ->anythingelse (fft/linalg/... - the 'lite' versions we have today)/

scicore's __init__ would have:

__all__ = ['whatever'] + ndarray.__all__

With this organization, we get:

1. The scicore package will provide all the necessary array functionality 
(which actually lives in ndarray), as well as a number of infrastructure 
utilities.  These are needed by scipy (full), but they can also be very useful 
to other scientifically-oriented packages.

This would mean that third-party library writers can rely on these useful 
tools, without the fear of pulling 'the full scipy behemoth' in as a 
dependency.  I know that, regardless of how much we succeed in making 
scipy_full work well and be easy to install, as a third-party author myself 
(for ipython), the thought of every new non-stdlib dependency for me requires 
very, very careful consideration.  Offering this light core as common ground 
could have beneficial effects in the long term, as it would be a good unifying 

2. If we ever decide to push anything into the python core proper, it would 
most likely be just (part or all of) ndarray.  This is the object targeted by 
Travis' array PEP, and the piece of most wide-ranging usefulness for 
non-scientific use (PIL, WX, etc.).

This would keep our namespaces isolated, so that if at some point in the 
future this is considered, one could just package ndarray standalone and give 
it to Guido and his team.  It might require a bit of distutils cleanup, but 
that's something we can worry about later (by that point, the functionality in 
scicore.distutils may even have been pushed upstream to the Python's official 

Aside from the necessary refactoring work right now, I don't see any major 
drawbacks to this, and do see benefits for the long term.



More information about the Scipy-dev mailing list