Currently, it isn't legal to perform <, >, <=, or >= rich comparisons on any complex objects, even though these operations are mathematically well-defined for real numbers.

The attached PR addresses this by defining rich comparisons for real-valued complex objects against subclasses of int and float, as well as for decimal.Decimal and fractions.Fraction types. They still raise TypeErrors when either of the operands has a nonzero imaginary part.

I don't think we should do this. In numerical computation we should not depend on exact floating point values, because is affected by computation errors. It would be hard to debug the program when some complex numbers are orderable, but other are not, and the difference between formers and latters is insignificant.

If you need to order real-valued complex object, convert them to float objects first.

I don't really see, though, how comparing complex(42) == float(42) is any less dangerous than complex(42) <= float(42). It seems odd to me, personally, that real-valued complex objects are valid for *some* rich comparisons (but not others) when the math is unambiguous.

-1 from me. The rules for when things are comparable or not should be kept simple.

-1. We don't want to have objects that are orderable depending on their values. I can't think of anywhere else we do this.

It would be very easy to have a complex == 42+0.0000001j, after some calculation. This near-zero imaginary part would prevent it from being orderable, while if a similar calculation produced exactly 42+0j, then that instance would be orderable. An application relying on this would be a nightmare to write comprehensive tests for.

Whether something is orderable or not should depend solely on its type, not its value.

> The rules for when things are comparable or not should be kept simple.

I think that the sort of user who uses complex numbers for their numerical calculations would still find this behavior "simple", but that may just be me.

> We don't want to have objects that are orderable depending on their values. I can't think of anywhere else we do this.

Well... tuples and lists behave this way. ;)

> An application relying on this would be a nightmare to write comprehensive tests for.

I'm not arguing that applications should rely on this behavior as core functionality, just that Python's more advanced math functionality deserves to be correct.

With that said, there are already so many weird limitations on complex numbers and floating-point values in general. I wouldn't expect users to treat comparing complex numbers any differently than they would treat comparing floats. Check check the .imag value in the former, check math.isnan in the latter.

NaN and complex numbers are not orderable by definition. This is a feature, not a bug.