[SciPy-dev] Moving random.py

[Pearu Peterson]

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