Charles R Harris wrote:
> Hi Travis,
>
> Could you expand on your thinking concerning NotImplemented? The
> relevant code is:
>
> /*
> * FAIL with NotImplemented if the other object has
> * the __r<op>__ method and has __array_priority__ as
> * an attribute (signalling it can handle ndarray's)
> * and is not already an ndarray
> */
> if ((arg_types[1] == PyArray_OBJECT) && \
> (loop->ufunc->nin==2) && (loop->ufunc->nout == 1)) {
> PyObject *_obj = PyTuple_GET_ITEM(args, 1);
> if (!PyArray_CheckExact(_obj) && \
> PyObject_HasAttrString(_obj, "__array_priority__") && \
> _has_reflected_op(_obj, loop->ufunc->name)) {
> loop->notimplemented = 1;
> return nargs;
> }
> }
>
> And the check is made after the needed promotions have been determined
> and stored in arg_types. Consequently if a type is promoted to an
> object array, as happens for the shift operations with floating
> scalars, the rest of the conditions will be checked and pass because
> numpy scalar types aren't arrays. I wonder if that is what you
> intended here?
I'm not sure, I don't understand what problem you are trying to solve.
> The reason I ask is that this determination should be associated with
> the standard slot functions when the call is made and I don't want to
> worry about type promotions. Further, I wonder why you want this
> return before the attempt to run the function with the current
> arguments is made. So it would be very helpful if you could clarify
> what you aim to achieve here.
This is to ensure that object arrays get a chance to run their own code
if they have the required right-hand special name (e.g. __radd__).
The problem is that NumPy is very aggressive and tries to handle
everything so if I let the code get past this point, it would run
successfully as an object array which is not what is necessarily wanted
-Travis
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
