On Fri, 16 Dec 2005, Travis Oliphant wrote:
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 agree.
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()
I like this approach quite a bit. That way coders could choose packages as desired. And interactive use could be made easy as well.
What do you think Pearu? You're probably the best one suited to make it happen.
Instead of import scipy scipy.import_all() we could have import scipy.import_all or similar such as `import scipy.all` etc. Though having a function import_all() would have an advantage of specifying packages one wishes to see in scipy namespace: import_all('linalg','integrate') would import only scipy.linalg and scipy.integrate packages and their dependencies if there are any. import_all() would import all scipy packages. Hmm, may be scipy.import_all should read as scipy.import and scipy.import() would be scipy.import('all'). However, using Python keyword `import` as a function name would be showstopper here, just import_all does not sound right when it could have optional arguments. Suggestions for better names are welcome. I have another question: what would be in scipy namespace when one types import scipy ? base, test, basic modules. What else? Pearu