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

[Blair]

Blair <bidih...@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 <dicki...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

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

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
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:dicki...@gmail.com";>dicki...@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:rep...@bugs.python.org";>rep...@bugs.python.org</a>&gt;<br>
&lt;<a 
href="http://bugs.python.org/issue5211";>http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________</blockquote>

_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com