Mark Dickinson <dicki...@gmail.com> added the comment:
[Serhiy] > What about math.trunc() and round()? Should they return int or float? math.trunc was deliberately introduced to be an explicitly-value-modifying conversion to int (as opposed to "int" itself, which is used for both lossy and lossless conversions to int); so from that perspective it should return int. round is less problematic than floor and ceil because it provides a way to preserve the type (by using `0` as the second argument). Single-argument round frequently turns out to be the right way to convert a float to an int in practice (e.g., in something like `nsteps = round((stop - start) / step)`, in a case where you know in advance that mathematically stop - start is a small integer multiple of step, but floating-point errors might cause the quotient to deviate from that integer by a small amount in either direction), so I've often appreciated the convenience of being able to use `round(some_float)` instead of `int(round(some_float))`. Floor division of floats already returns a float, and I can't see a strong reason to change that. It's not exactly the most useful floating-point operation in the first place, so it's hard to find use-cases that argue for one return type over the other. But I think all of this is academic: it's another case of "Should we have done this differently in the first place?" versus "Should we change it now?". The answer to the first question *might* be "Yes" for some pieces, but the answer to the second is almost certainly "No". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38813> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
