[SciPy-dev] Moving random.py
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
I'd suggest having in scipy's top level a single method import_all, so that
one could write:
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).
More information about the Scipy-dev