[SciPy-dev] scipy import failures, what can we do about it?
Travis Oliphant
oliphant at ee.byu.edu
Tue Feb 26 14:30:17 CST 2002
>
> Ok, this would be helpful in cases where importing of, say, clapack
> fails, then instead of showing plain messages with missing symbols, a
> message something like 'fix your atlas installation' is shown.
>
> But I am not sure that this will fix the scipy importing failure messages,
> what you get is just a replaced failure message and there will be
> still alien failure messages.
>
> I don't understand the purpose of functions like modules2all,
> names2all, etc. For example, why linalg.__init__.py contains
>
> _modules = ['fblas', 'flapack', 'cblas', 'clapack']
> _namespaces = ['linear_algebra']
> __all__ = []
> import scipy
> scipy.modules2all(__all__, _modules, globals())
> scipy.names2all(__all__, _namespaces, globals())
>
> instead of plain and explicit
>
> from linear_algebra import __all__
> from linear_algebra import *
>
> And if scipy/__init__.py has
>
> from linalg import *
>
> then doing 'import scipy', the failure of importing clapack would
> raise an exception showing a direct location of the problem.
Thanks for raising these issues, Pearu. What is currently there is done
for the purpose of easily adding new namespaces. It is done because of
my current understanding of the way Python deals with Packages and names.
The reason we don't do as you describe is because I wanted to make sure
that the __all__ variable was updated anytime a new name space was
imported. They are convenience functions. They are not necessary,
provided what the code does is done every time.
>
> Sorry, if I don't understand the big picture of scipy structure, I have
> always thought that keeping modules independent would be a good thing but
> current scipy hooks seem to try to integrate all modules and their
> namespaces into a one big one. I must be missing something obvious...
> Could someone direct me into the right path here if possible?
The problem is that we want the user to have access to a series of
submodules under the scipy namespace, e.g.
scipy.optimize.fsolve
scipy.special.gammainc
We also want the user of scipy to have access to some "basic" functions
which may actually be defined in another subpackage. We want these to be
in the main scipy namespace, e.g.
scipy.fft
scipy.polyval
We also want the user to do be able to say
from scipy import *
and have this be the equivalent of getting rid of the scipy name in front
of all of the previous commands, so
optimize.fsolve
fft
special.gammainc
polyval
all work as expected.
The problem is due to faulty file systems on Windows and MAC OS platforms
( :-) ) that mangle the case of file names. This requires that for
packages modules must be explicitly loaded and the __all__ variable set in
the __init__.py file (this is my understanding anyway).
Otherwise
from package import *
won't load all the names accessible as
package.XXXX
That's the general idea. The implementation certainly isn't set in stone.
-Travis
More information about the Scipy-dev
mailing list