round

[Steven D'Aprano]

On Thu, 07 Jun 2018 13:09:18 +0200, ast wrote:

> Hi
> 
> round is supposed to provide an integer when called without any
> precision argument.

True, but that's really under the control of the object you feed it to.

It would be possible for round() to enforce that, but it might break code 
that relies on having __round__ return a non-int.


[...]
> round(np.linalg.det(M))
> -18.0 # i was expecting an integer -18, not a float

Yes, that's surprising, but I'm not sure if that's a bug or not, and if 
it is a bug, whether it counts as a bug in round() or in numpy.

Most Python operators and functions that call dunder methods specify the 
*expected* but not *mandatory* behaviour. There are a few exceptions:

py> class BadClass:
...     def __len__(self):
...             return "Surprise!"
...
py> x = BadClass()
py> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object cannot be interpreted as an integer


but generally it is up to the object itself to do the right thing, or 
else have a good reason not to.

My feeling here is that this *probably* counts as a bug in numpy, but I'm 
open to persuasion otherwise.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson