This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: bug with round() and "numpy floats"
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.8, Python 3.7, Python 3.6
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Scaler, docs@python, mark.dickinson, pablogsal
Priority: normal Keywords:

Created on 2019-05-10 20:51 by Scaler, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (4)
msg342132 - (view) Author: (Scaler) Date: 2019-05-10 20:51
round()'s documentation ( says that "The return value is an integer if ndigits is omitted or None."

Works well with "built-in floats", but not with "numpy floats" (didn't know they were different):
>>> import numpy as np
>>> round(5.5)
>>> round(np.round(5.5)-0.5)

As a side note, is there any reason why round() does not return value as an integer if ndigits is 0 or negative also?
msg342140 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-05-10 22:12
round() delegates to class.__round__, so what's happening here is that numpy's float implements __round__ in a way it returns a float.

There is no restriction on what the class can return:

>>> class A:
...     def __round__(self):
...         return "Oh, no!"
>>> round(A())
'Oh, no!'

Making additional restrictions is backwards incompatible. Maybe we should add something in the docs regarding the no-restriction point.
msg342180 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-05-11 10:28
> Maybe we should add something in the docs regarding the no-restriction point.

IMO, the docs are clear enough (and also long enough) already here. Just as with most other magic methods, classes from third-party packages can return whatever they like. It doesn't seem worth adding specific disclaimers about this everywhere that a magic method might be used. Otherwise, we should also add corresponding disclaimers about `__floor__`, `__ceil__`, `__trunc__`, `__pow__`, and so on, and I think that would just introduce an increase in documentation size without any overall increase in clarity or usefulness.

I'd prefer to stick to documenting that there _is_ a restriction where that's true (e.g., `__index__` or `__hash__`).
msg342181 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-05-11 10:30
BTW, there are various issues already open in the NumPy bug tracker, for example

I propose closing this as "third party".
Date User Action Args
2022-04-11 14:59:15adminsetgithub: 81060
2019-06-02 09:10:40mark.dickinsonsetstatus: open -> closed
resolution: third party
stage: needs patch -> resolved
2019-05-11 10:30:45mark.dickinsonsetmessages: + msg342181
2019-05-11 10:28:53mark.dickinsonsetmessages: + msg342180
2019-05-11 10:02:23mark.dickinsonsetnosy: + mark.dickinson
2019-05-11 06:07:07SilentGhostsetresolution: not a bug -> (no value)
stage: needs patch
2019-05-10 22:13:21pablogsalsetversions: + Python 3.7, Python 3.8
nosy: + docs@python

assignee: docs@python
components: + Documentation
resolution: not a bug
2019-05-10 22:12:35pablogsalsetnosy: + pablogsal
messages: + msg342140
2019-05-10 20:51:01Scalercreate