@AVicennA: as the docs you linked to explain, this is not a bug: `round` is giving the correct result in all cases (or at least, as correct as is possible given the use of binary floating-point).

Let's take just the first case, `round(2.675, 2)`. `2.675` is a numeric literal in the source that's converted to a Python object of type `float` whose value is stored[*] using the IEEE 754 binary64 format. The exact value of that object is then 2.67499999999999982236431605997495353221893310546875.

So the value that Python sees when rounding is *less* than the halfway case 2.675, so it rounds down to 2.67. If you think that's not the right thing to do, I have a question for you: what result would you expect `round(2.6749999999999998, 2)` to give?

Your proposed my_round replacement is not a fix: unlike *round*, it does *not* do correct rounding in all cases, and does not always give the naively expected result in all cases either. To give just one example of many:

    >>> my_round(4.395, 2)
    4.39

So I don't really understand what action you're proposing here. `round` is as good as it can reasonably be, and the documentation already explains the weaknesses and links to further reading. Unless you're proposing that Python adopt decimal floating-point for its core float type, or that two-argument round be deprecated, there not really anything to be done here.

[*] Disclaimer: use of IEEE 754 is not guaranteed, but is overwhelmingly likely on common platforms.