This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gumtree
Recipients gumtree, mark.dickinson, meador.inge
Date 2010-11-26.18:41:23
SpamBayes Score 4.63518e-14
Marked as misclassified No
Message-id <>
I see your point Mark, however it does not seem to be the right way to do

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 <> 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)
>>> 3.0 + xint(5)  # xint.__radd__ not called.

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 <>
File name Uploaded
unnamed gumtree, 2010-11-26.18:41:22
Date User Action Args
2010-11-26 18:41:24gumtreesetrecipients: + gumtree, mark.dickinson, meador.inge
2010-11-26 18:41:23gumtreelinkissue5211 messages
2010-11-26 18:41:23gumtreecreate