[SciPy-dev] Renaming scipy_core ???

[Travis Oliphant]

Fernando brings up an interesting point that might be worth some 
discussion.  It's might be too late to have this discussion, but with a 
more stable release coming up, it might not be.

Here is what he says:

> My main point is this: I worry a little that using 'scipy' as a single 
> name
> for both scipy_core and scipy_full is causing more problems than it 
> solves,
> and may be an unnecessary long-term headache.  There is the issue of 
> confusion
> of installation amongst newbies, as well as technical problems with 
> packaging
> because of file collisions, package manager issues, etc.
>
> Finally, there is the problem that when reading code, with something 
> like:
>
> import scipy
> scipy.foo.bar()
>
> there is no way to tell whether this uses scipy_core or _full.
>
> I wish I had expressed this earlier, but these thoughts really took a 
> while to
> clarify in my mind, as I didn't realize at the beginning that this 
> could be a
> problem.  But as time goes on, I am more and more convinced that we 
> may be
> setting ourselves up for an unnecessary long-term maintenance and user
> explanation headache.
>
> I wonder if we wouldn't be better off with the scipy_core package 
> being named
> something else altogether, let's say 'ndarray' (or whatever: I suck at 
> coming
> up with good names).  That package would contain 
> ndarray.{f2py,distutils,...}
> and it would be obviously a dependency for all scipy users.  In 
> ndarray, we'd
> define the __all__ attribute to explicitly list the publicly exported
> functions, classes and packages, and scipy would be assumed to do:
>
> from ndarray import *
> __all__ = ndarray.__all__ + ['whatever else scipy declares']
>
>
> So scipy would be known to be a strict superset of the core, as it is 
> today.


I would like to hear some more opinions about this.  The one that is 
most convincing to me is that
you can't tell if something comes from full scipy or scipy_core just by 
looking at the import statement.

That's an interesting concern.  I know, this would require quite a bit 
of re-factoring.  So, I'm not sure it is worth it.
It might help with the image of scipy_core.

We could call the scipy_core package scicore, or numcore, if that is the 
only concern.  The biggest concern is that right now, a lot of the 
sub-package management system is builtin to scipy_core from the get-go.  
That would have to be re-factored.  I'm not sure how easy that would be.

I'm ambivalent at this point, and mostly concerned with "moving forward" 
and having people view scipy_core as relatively stable....

-Travis