On Tue, Jun 24, 2008 at 12:46 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> 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.
>

1) NotImplemented is associated to specific types, hence the CHECKABLE flag
on the type.
2) It is a message to the python interpreter, not to the user.
3) It is associated with the slot functions of numeric types, not with
general functions.

When python encounters something like a + b, it looks at the CHECKABLE flag
on a. If set, it calls a.__add__ with b as is, not attempting to promote the
type. If that fails, a.__add__ returns NotImplemented, telling the
interpreter to do something, probably try the b.__radd__. If that fails it
raises an error.

If the *user* ever sees NotImplemented, it is a bug. Some of the numpy
ufuncs exhibit this bug and we should fix it.


> 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
>

The problem is that numpy has a *bug*. I am trying to fix it and I want your
help figuring out how to do so while preserving the behavior you had in
mind. So if you could point out specific cases you were thinking of it would
help me with this.

Chuck
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to