[SciPy-dev] tests, relative import: what's best ?
David Cournapeau
david@ar.media.kyoto-u.ac...
Mon Nov 26 04:51:34 CST 2007
Robert Kern wrote:
> David Cournapeau wrote:
>> Hi,
>>
>> I have a question regarding tests and import in numpy/scipy in
>> general. When implementing tests, the package to be tested has to be
>> imported, and there are two possibilities on how to do it (both are used
>> in scipy). Taking an hypothetical package foo in scipy as an example:
>>
>> 1 : using set_package_path /restore_path facilities of
>> numpy.testing, and do a "relative" import
>>
>> set_package_path()
>> from foo import bar
>> restore_path()
>>
>> This means that you can test the package foo without building the whole
>> scipy source tree. This is for example used in scipy.linalg tests. It
>> also correspond to DISTUTILS.txt doc in numpy/doc.
>>
>> 2 : using set_package_path / restore_path facilities, and do a
>> "absolute" import:
>>
>> set_package_path()
>> from scipy.foo import bar
>> restore_path()
>>
>> In this case, I don't understand why set_package_path is used ? And
>> also, this means that you cannot test the subpackage by itself, you need
>> to install the whole scipy tree. This is for example used in
>> scipy.signal tests.
>>
>> Are there any advantages to 2 ? If not, would it be a good idea to
>> convert every package to convention 1 ?
>
> If we can, I'd prefer that we simply make build_src/build_ext --inplace work for
> numpy and scipy and then remove set_package_path() and restore_path().
I didn't know about this option of distutils. I've just tried it on some
packages, it seems to just put the extensions and python files outside
the usual build directory ? This way, we should follow the first method,
but without messing sys.path ?
What does not work with numpy/scipy related to --inplace ?
David
More information about the Scipy-dev
mailing list