[SciPy-dev] Renaming scipy_core ???
Fernando.Perez at colorado.edu
Tue Jan 3 01:51:06 CST 2006
Travis Oliphant wrote:
>>My idea of ndarray is simply to keep the pure array functionality fairly
>>standalone, thinking of potential inclusion of that part in the python core at
>>some point, or of the needs of embedders, py2exe, py2app users, etc. I never
>>thought that a user would ever do
>>from numerix.ndarray import ...
>>because we'd have, in the numerix __init__ file,
>>__all__ = numerix.__all__ + ['more','stuff']
> Great (assuming you mean __all__ = ndarray.__all__ + ... ;-) )
yup, sorry :)
> That's what I'm thinking, too. But should we clobber the
> numerix.ndarray *sub-package* with the numerix.ndarray.ndarray
> *object*. Isn't that the kind of thing we are trying to avoid doing?
> So, that somebody could do import numerix.ndarray if they were pedantic?
Mmh, I'm confused. I thought that the 'array' object would be _defined_ in
the ndarray package, and would only 'propagate up' to the numerix namespace
via the above mechanism. So I guess that somebody could do, if they wanted
from numerix import ndarray
x = ndarray.array([1,2,3])
since ndarray would be a normal python package (a sub-package of numerix,
hence automatically found by python if it lives in a sub-dir of numerix/ and
has an __init__ file).
The point is that WE will never ship ndarray as a standalone package, but
there will be nothing technically preventing that from being done. This
isolation will probably keep us in check design-wise, as well as allowing
somebody who may need just the array functionality for an embedded/py2exe
project to grab it.
None of this seems like unnecessary namespace pollution to me. But again:
don't worry, and move on. Make the decision you feel best with, and go ahead.
We have work to do ;) Announce a final form, and the anxious doc-writers
and website gang can get to documenting the currently incomprehensible mess
into a nice, clear and compact set of instructions for newcomers.
More information about the Scipy-dev