There several mixed issues here.
1. PEP 3141 https://www.python.org/dev/peps/pep-3141/ compliance.
Numpy scalars are `numbers.Real` instances, and have to respect the `__round__` semantics defined by PEP 3141:
def __round__(self, ndigits:Integral=None): """Rounds self to ndigits decimal places, defaulting to 0.
If ndigits is omitted or None, returns an Integral, otherwise returns a Real, preferably of the same type as self. Types may choose which direction to round half. For example, float rounds half toward even.
"""
This means that if Real -> Real rounding is desired one should call `round(x, 0)` or `np.around(x)`.
This semantics only dictates that the return type should be Integral, so for `round(x)` and `round(x, None)`
np.float32 -> np.int32 np.float32 -> np.int64 np.float64 -> np.int64 np.floatXX -> int
are all OK. I think also that it is perfectly OK to raise an overflow on `round(x)`
2. Liskov substitution principle
`np.float64` floats are also `float` instances (but `np.float32` are not.) This means that strictly respecting LSP means that `np.float64` should round to python `int`, since `round(x)` never overflows for python `float`.
Here we have several options.
- round `np.float64` -> `int` and respect LSP.
- relax LSP, and round `np.float64` -> `np.int64`. Who cares about `round(1e300)`?
- decide that there is no reason for having `np.float64` a subclass of `float`, so that LSP does not apply.
This all said, I think that these are the two most sensible choices for `round(x)`:
np.float32 -> np.int32 np.float64 -> np.int64 drop np.float64 subclassing python float
or
np.float32 -> int np.float64 -> int keep np.float64 subclassing python float
The second one seems to me the less disruptive one.
Bye
Stefano