[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'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 <<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>> added the comment:<br><br>
I think that's expected behaviour. Note that int vs float behaves in the same way as float vs complex:<br><br>
>>> class xint(int):<br>
...    def __radd__(self, other):<br>
...        print "__radd__"<br>
...        return 42<br>
... <br>
>>> 3 + xint(5)<br>
__radd__<br>
42<br>
>>> 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 <<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>><br>
<<a href="http://bugs.python.org/issue5211">http://bugs.python.org/issue5211</a>><br>
_______________________________________</blockquote>
More information about the Python-bugs-list
mailing list