Hi John, you said:

> it seems that sorted built-in always return floats before int if they appear to be equal

But that's not correct:

>>> sorted([5.0, 5])
[5.0, 5]
>>> sorted([5, 5.0])
[5, 5.0]


Python's sort is *stable*, which means that the order of two equal values will always be the same as before they were sorted.

You then ask:

> So, what about trying to "store" if some float is 12 "in limit" of 12 but from "left/-"? So then it is < than 12.


Short answer: no.

Longer answer: no, we're not going to complicate and slow down both floats and sorting in order to give "do what I mean" results for sorting.

What you are seeing is a fundamental limitation of floating point arithmetic. On the web, you can find dozens of sites that talk about this, in pretty much every single programming language with floating point numbers. You might like to start with the Python FAQ:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

In your case, you are being tripped up by the fact that there is no such float as either 11.9999999999999999 or 12.0000000000000001. Both of those are rounded to *exactly* 12.0, as the float data type only has (approximately) 17 decimal places of precision.

This is a fundamental feature of floating point numbers and there is nothing we can do about that without massively complicating and slowing down floats.

By the way, Decimal are floating point numbers too. They are equally affected by this, except that being stored in decimal with more digits by default, rather than binary, it is not so easy to trip over it. But it can certainly happen to Decimals as well.