[Numpy-discussion] NotImplementedType should be an exception

Charles R Harris charlesr.harris@gmail....
Sat Jun 21 15:00:48 CDT 2008


On Sat, Jun 21, 2008 at 12:01 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:

>
>
> On Sat, Jun 21, 2008 at 8:57 AM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Sat, Jun 21, 2008 at 7:39 AM, Travis E. Oliphant <
>> oliphant@enthought.com> wrote:
>>
>>> Charles R Harris wrote:
>>> > Shouldn't this raise an NotImplementedError exception?
>>> >
>>> > In [7]: type(remainder(complex192(1), complex192(1)))
>>> > Out[7]: <type 'NotImplementedType'>
>>> I'm not sure if it is relevant in this case but we do need to keep in
>>> mind that Python uses the NotImplementedType as a signal to hand off the
>>> calculation to the other object in a binary operation.
>>>
>>> If we change this here we may affect that behavior, unintentionally.
>>>
>>
>> But Python only does that if the Py_TPFLAGS_CHECKTYPES bit in the tp_flag
>> is set. With that flag it should try with the other variable, then raise a
>> Type error if that fails also. That's why I think the flag isn't set for
>> these variables; we should never see the NotImplementedType. And at first
>> glance at the code, I don't think that flag *is* set for the type.
>>
>
> This particular return comes from ufunc_generic_call and I'm not sure what
> Python should or can do in this case. Thoughts?
>

It looks like Py_NotImplemented is a message to the python interpreter and
should not be visible to the user. So in this case I think we should raise
an exception.

PEP 208: New Coercion Model

How numeric coercion is done at the C level was significantly modified. This
will only affect the authors of C extensions to Python, allowing them more
flexibility in writing extension types that support numeric operations.

Extension types can now set the type flag Py_TPFLAGS_CHECKTYPES in their
PyTypeObject structure to indicate that they support the new coercion model.
In such extension types, the numeric slot functions can no longer assume
that they'll be passed two arguments of the same type; instead they may be
passed two arguments of differing types, and can then perform their own
internal coercion. If the slot function is passed a type it can't handle, it
can indicate the failure by returning a reference to the
Py_NotImplementedsingleton value. The numeric functions of the other
type will then be tried,
and perhaps they can handle the operation; if the other type also returns
Py_NotImplemented, then a TypeError will be raised. Numeric methods written
in Python can also return Py_NotImplemented, causing the interpreter to act
as if the method did not exist (perhaps raising a TypeError, perhaps trying
another object's numeric methods).

 Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080621/577b6ec1/attachment.html 


More information about the Numpy-discussion mailing list