[SciPy-dev] Renaming scipy_core ???
Fernando Perez
Fernando.Perez at colorado.edu
Sun Jan 1 15:31:13 EST 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:
scicore/
__init__.py
->ndarray/
__init__.py
->f2py/
->weave/
->distutils/
->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
layer.
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
distutils).
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.
Regards,
f
More information about the SciPy-Dev
mailing list