trac user jpeel wrote on 2011-01-04

The sqrt and log in examples above appear to be fixed in 2.0.0.dev-9451260. However, the following Numpy functions still have this problem:

power, add, subtract, multiply, divide, bitwise_and, bitwise_or, bitwise_xor, floor_divide, fmax, fmin, fmod, greater, greater_equal, hypot, less, less_equal, logaddexp, logaddexp2, logical_and, logical_or, logical_xor, maximum, minimum, mod, and not_equal.

Attachment added by trac user jpeel on 2011-01-04: 0001-BF-fix-for-raising-NotImplemented-rather-than-return.patch

trac user jpeel wrote on 2011-01-04

All of the Numpy functions that I mentioned above were all ufuncs that took two arguments. There was some code for handling errors in ufunc_object.c that returned Py_NotImplemented when there were two arguments to the function rather than raising the NotImplemented exception. The comment by this code said 'To allow the other argument to be given a chance'. I don't see how that comment makes any sense. Does anyone know why this is in there?

The patch I submitted removes these lines so that the correct exception is raised.

Still a problem, patch should be applied.

When supplied patch is applied to current master (17227ce130cae09f) running the tests leads to errors, failures and eventually segfaults.

I will also add that there is some behavior in NumPy that is dependent on ufunc's returning NotImplemented. See comment in #4470.

This issue is exacerbated by the fact that NotImplemented is happily wrapped in an (object) array:

>>> np.array(NotImplemented)
array(NotImplemented, dtype=object)

this leads to hard to debug errors that occur long after the operands that resulted in NotImplemented are gone.

Maybe np.array(NotImplemented) should be an error.

Whoa, nasty.

The problem here comes from conflating Python binop interface with ufuncs, and the best fix would be just move the NotImplemented returns into the binop layer. Ufuncs themselves should likely raise TypeErrors in the cases where they currently return NotImplemented.

I think simply changing this may be possible in master. AFAIK we now should be checking the binop explicitly first.

This has been dealt with by #5964 / #5864.