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.

Author mark.dickinson
Recipients JBernardo, docs@python, mark.dickinson, r.david.murray, vajrasky
Date 2013-12-09.19:07:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

All this changed as part of PEP 3141.  I wasn't watching Python 3 development closely back then, but I *think* at least part of the motivation was to provide a way to get away from the use of `int` to truncate a float to its integer part:  the argument goes that a simple type conversion shouldn't throw away information, and that if you want a transformation from float to int that throws away information you should ask for it explicitly.  So `math.trunc` was born as the preferred way to truncate a float to an int, and `math.floor`, `math.ceil` and `round` became alternative float -> int conversion methods.  That entailed those functions returning ints.

<off-topic> In the case of `math.floor` and `math.ceil` at least, I think this is regrettable.  There are plenty of places where you just want a float -> float floor or ceiling, and Python no longer has a cheap operation for that available:  floor as a float-to-float operation is cheap;  floor as a float-to-long-integer operation is significantly more costly.

In the case of `round`, we still have `round(x, 0)` available as a cheap float->float conversion, so it's less of a problem.  And I hardly ever use `trunc`, so I don't care about that case. </off-topic>
Date User Action Args
2013-12-09 19:07:00mark.dickinsonsetrecipients: + mark.dickinson, r.david.murray, docs@python, JBernardo, vajrasky
2013-12-09 19:07:00mark.dickinsonsetmessageid: <>
2013-12-09 19:07:00mark.dickinsonlinkissue19933 messages
2013-12-09 19:07:00mark.dickinsoncreate