[SciPy-dev] Renaming scipy_core ???
oliphant.travis at ieee.org
Sat Dec 31 19:08:09 CST 2005
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
> for both scipy_core and scipy_full is causing more problems than it
> and may be an unnecessary long-term headache. There is the issue of
> of installation amongst newbies, as well as technical problems with
> because of file collisions, package manager issues, etc.
> Finally, there is the problem that when reading code, with something
> import scipy
> 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
> up with good names). That package would contain
> 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
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....
More information about the Scipy-dev