> In my opinion, 2.6.6 was faulty in the float + xint case, for the same
> reasons as above, and 2.7 is faulty in both float + xint and complex +
> xint.

Well, I disagree:  Python is behaving as designed and documented in these cases.  If you want to argue that the *design* decisions are the wrong ones, then I'd suggest opening a discussion on the python-ideas mailing list, where more people are likely to get involved---this tracker isn't really the right place for that sort of discussion.

Leaving complex out of the mix for the moment, it sounds to me as though you'd like, e.g.,

<float> + <subclass of int>

to call the int subclass's __radd__ method (if it exists) before calling the float's __add__ method.  Is that correct?

Or are you suggesting that float's __add__ method shouldn't accept instances of subclasses of int at all?  (i.e., that float.__add__ should return NotImplemented when given an instance of xint).

In the first case, you need to come up with general semantics that would give you the behaviour you want for float and xint---e.g., when given numeric objects x and y, what general rule should Python apply to decide whether to call x.__add__ or y.__radd__ first?

In the second case, I'd argue that you're going against the whole idea of object-oriented programming; by making xint a subclass of int, you're declaring that its instances *are* 'ints' in a very real sense, so it's entirely reasonable for float's __add__ method to accept them.

In either case, note that Python 2.x is not open for behaviour changes, only for bugfixes.  Since this isn't a bug (IMO), such changes could only happen in 3.x.

Please take further discussion to the python-ideas mailing list.