[SciPy-dev] Renaming scipy_core ???

[Fernando Perez]

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.

Cheers,

f