On Tue, 7 Dec 2004, Todd Miller wrote:
Note that assert_equal, assert_almost_equal, assert_approx_equal were not meant to be used with array arguments (I didn't implement them but its obvious from reading the code).
Thanks for pointing this out... I noticed the array versions only peripherally and didn't understand the distinction.
May be we need to review assert_equal, etc so that they will handle array inputs similar to assert_array_equal but on Python objects they will not use unnecessary scipy_base.all. And then define assert_array_equal = assert_equal assert_array_almost_equal = assert_almost_equal in testing.py for backward compability and declare their use as depreciated.
For checking the equality of array arguments assert_array_equal or assert_array_almost_equal should be used. If some scipy test suite uses assert_equal, etc with array arguments then I think this is a bug of this particular test suite, not of testing.py. So, using scipy_base.all in assert_equal, etc is not necessary (unless we want to drop assert_array_* functions).
Understood. Are we agreed that it is appropriate to use all() in the assert_array_* functions?
Yes. But be careful when replacing `if obj:` with `if all(obj):` in other parts of scipy as it may also mean `if any(obj):` or `if obj is not None:`, in fact, I think these are being assumed in most cases. And if not, then it should be a bug. I agree that the usage of `if obj:` is a bug and should be fixed either to `if any(obj):` or `if obj is not None:` or rarely `if all(obj):`. Pearu