[SciPy-dev] Moving random.py

[Pearu Peterson]

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