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@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:
>>> class xint(int):
... 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@bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________