[issue5211] Fix complex type to avoid coercion in 2.7.

Blair report at bugs.python.org
Fri Nov 26 19:41:24 CET 2010


Blair <bidihall at gmail.com> added the comment:

I see your point Mark, however it does not seem to be the right way to do
this.

Are you aware that Python has formally specified this behaviour somewhere? I
could not find an explicit reference in the documentation.

The problem that has been fixed is covered in the documentation:

(3.4.8. Emulating numeric types: Note
If the right operand’s type is a subclass of the left operand’s type and
that subclass provides the
reflected method for the operation, this method will be called before the
left operand’s non-reflected method.
This behavior allows subclasses to override their ancestors’ operations.)

This rule is needed so that mixed-type arithmetic operations do not revert
to the ancestor's type. However, one would expect that different numeric
types (int float complex)  would all behave in a similar way. For example,

xi = xint(3)
3 + xi  # is an xint(6)
3.0 + xi # is float(6)

This is the same problem as the one that has been fixed from a practical
point of view. Such behaviour is not going to be useful (IMO).

It seems to me that xint.__radd__ would need to be called if the left
operand is a subclass of any of the number types (in this case,
isinstance(left_op,numbers.Complex) == True).

Am I missing something?

Mark Dickinson <dickinsm at gmail.com> added the comment:

I think that's expected behaviour.  Note that int vs float behaves in the
same way as float vs complex:

...     def __radd__(self, other):
...         print "__radd__"
...         return 42
...
>>> 3 + xint(5)
__radd__
42
>>> 3.0 + xint(5)  # xint.__radd__ not called.
8.0

As with your example, the float.__add__ method is happy to deal with an int
or an instance of any subclass of int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

----------
Added file: http://bugs.python.org/file19828/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
I see your point Mark, however it does not seem to be the right way to do this. <br><br>Are you aware that Python has formally specified this behaviour somewhere? I could not find an explicit reference in the documentation.<br>
<br>The problem that has been fixed is covered in the documentation:<br><br>(3.4.8. Emulating numeric types: Note<br>If the right operand’s type is a subclass of the left operand’s type and that subclass provides the<br>reflected method for the operation, this method will be called before the left operand’s non-reflected method.<br>
This behavior allows subclasses to override their ancestors’ operations.)<br><br>This rule is needed so that mixed-type arithmetic operations do not revert to the ancestor&#39;s type. However, one would expect that different numeric types (int float complex)  would all behave in a similar way. For example,<br>
<br>xi = xint(3)<br>3 + xi  # is an xint(6)<br>3.0 + xi # is float(6)<br><br>This is the same problem as the one that has been fixed from a practical point of view. Such behaviour is not going to be useful (IMO). <br><br>
It seems to me that xint.__radd__ would need to be called if the left operand is a subclass of any of the number types (in this case, isinstance(left_op,numbers.Complex) == True). <br><br>Am I missing something? <br><br>
<blockquote type="cite" class="cite" cite="">Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br><br>
I think that&#39;s expected behaviour.  Note that int vs float behaves in the same way as float vs complex:<br><br>
&gt;&gt;&gt; class xint(int):<br>
...     def __radd__(self, other):<br>
...         print &quot;__radd__&quot;<br>
...         return 42<br>
... <br>
&gt;&gt;&gt; 3 + xint(5)<br>
__radd__<br>
42<br>
&gt;&gt;&gt; 3.0 + xint(5)  # xint.__radd__ not called.<br>
8.0<br><br>
As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int.<br><br>
----------<br><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5211">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________</blockquote>


More information about the Python-bugs-list mailing list