> I really don't know why you would desire a different result.

I found it surprising that a comparison uses a different method of conversion than the (obvious) user-side conversion, with a different outcome. This seems to be implementation details leaking into the user side.


> "That's also what the code says."

I wasn't referring to a specific comment. What I meant was that the code in float_richcompare() goes to great length trying to convert the integer to a float in a safe way so that it can compare the two values.

https://github.com/python/cpython/blob/985ac016373403e8ad41f8d563c4355ffa8d49ff/Objects/floatobject.c#L403

I now see that it goes the other way at the end, though. If both values have the same order of magnitude, then it actually converts the float to a PyLong instead, thus choosing one of the integer values out of the value range that the float spans and comparing that. That's where the difference originates.


> If you want to compare values approximately as floats, you should explicitly convert them to floats.

As I wrote, "I'm not sure if I should consider this a bug", because it's an area that we could just define as "out of bounds behaviour" and "user, you're on your own".

The net effect is that some integers will never equal a floating point value, even though the floating point value does its very best to represent that integer.

I can live with considering the current behaviour "as good as it gets, because there is no right way to do it".

Thank you for your comments.