On Fri, 16 Dec 2005, Travis Oliphant wrote:
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.
random.py does not need to be under basic to make rand, randn to appear in scipy namespace. When moving random.py to scipy/, the full scipy needs some fixes too, several modules do 'from scipy.basic.random import ..'.
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.)
see a comment at the end of this message..
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.
The speed of importing full scipy without ppimport hooks has been improved a lot when using Python2.3 and up (and faster computers). I myself do not consider the import speed a big issue anymore.
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.
I just realized that scipy could do similar to Maple when importing packages that provide global symbols. For example, when executing import scipy.fftpack in interactive shell then code like (untested, unoptimized) from scipy.distutils.misc_util import get_frame if get_frame(1).f_locals['__name__']=='__main__': # expose fft to interactive shell exec 'fft = scipy.fftpack.fft' in get_frame(1).f_locals,get_frame(1).f_globals at the end of fftpack/__init__.py would expose fft function to interactive shell (Maple would show also a warning on changing global namespace if I recall correctly). Pearu