[SciPy-dev] Moving random.py

Fernando Perez Fernando.Perez at colorado.edu
Fri Dec 16 18:55:30 CST 2005


Gary Ruben wrote:
> 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 *

I think this is a good idea, but I'd implement it just a little differently. 
The convenience of scipy.* can be great for code that uses a lot of scipy, so 
you don't have to type

import scipy.this, scipy.that, scipy.that_else,...

But I tend to agree with R. Kern that the black magic played by scipy's 
delayed importer tends to (at least it has in the past, though in fairness 
it's currently pretty much OK) cause problems.

I also think that even though scipy starts pretty fast these days, it would 
still be a good idea to keep its init time to a minimum, especially for 
software that is run many times with a fresh process (like unit tests, for 
example).

I'd suggest having in scipy's top level a single method import_all, so that 
one could write:

import scipy
scipy.import_all()

and from then on use:

scipy.this.foo() + scipy.that.bar()

This simple idiom could be used in most code that needs to access a lot of 
scipy, and yet it doesn't pollute the user's global namespace.

If you really want a full top-level import, we could have an 'all' module:

from scipy.all import *

the 'all' module would be the one with the heavy-duty imports.  I'd name it 
'all' instead of 'interactive' because I think this describes better the fact 
that it contains 'all of scipy' (though as a matter of suggesting policy by 
naming, interactive is in fact better :)

With this in place, it's a trivial matter for any frequent scipy users to add 
to their ipython profile the above line (along with matploblib imports and 
anything else they may want).  This means it would work without any changes 
needed on ipython's side.

Note that I'm very happy to make any modifications needed to improve the 
interactive experience, but I like it even better if we can find solutions 
that don't require ipython changes (so they also benefit users of other 
interactive systems, including the plain python '>>>' shell).

Cheers,

f




More information about the Scipy-dev mailing list