[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".