I don't know if this is a stupid idea, but if the vote if for the magic to be moved to ipython, perhaps you could create a subpackage whose sole purpose was provide access to all subpackages in one hit a'la from scipy.interactive import * Gary R. Travis Oliphant wrote:
Hey Robert.
I temporariliy moved random back under basic for now. I did this because it's really important to me that rand, randn, fft, and ifft are in the scipy namespace. I don't want you to think I'm unsupportive of the general changes you are trying to see, though.
While in principle it would be nice to not do any import magic. There are three problems that I'd like to see solved that I think the import magic is trying to accomplish:
1) making some names visible in the scipy namespace (like fft, rand, etc.) 2) having some mechanism for scipy_core to use the tools in full scipy should it be installed (like svd, for example). 3) having some means to speed up importing.
I think that there are two views of how scipy should behave that need to be resolved.
The first view is where scipy is at right now in that when the user imports scipy the whole kit-and-kaboodle gets imported at the same time. This view was developed back when it was envisoned that scipy alone would be the MATLAB-like replacement. I think it is more clear now that IPython is better for interactive work and Matplotlib (and Enthought's coming tools) are better for plotting, that something else should provide the "environment for computing" besides the simple command import scipy.
The second view is that scipy should just be a simple name-space package and not try to do any magic. Users will primarily use scipy for writing code and will import the needed functions from the right places.
Most of what scipy is has been done to support interactive work, so that one does not have to do:
import scipy import scipy.integrate import scipy.special
in order to get access to the sub-packages. Perhaps this should be re-thought and something like this magic moved to IPython.
-Travis