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 mark.dickinson, rhettinger, serhiy.storchaka
Date 2021-08-22.15:56:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think the needs are sufficiently different that __trunc__ still has value as its own thing, and it's a natural counterpart to __floor__ and __ceil__ (out of all the directed rounding modes, rounding towards zero probably turns up more often than rounding towards +inf or -inf).

__int__ has the disadvantage that it must return an int, so it's not useful for other Python-based numeric systems with their own rational number / integer pairing. For example, with gmpy2, truncating an mpq instance returns an mpz instance, which is what I'd expect and want - if I'm working with huge values then it would be annoying for math.trunc to do the inefficient thing and return a plain int.

>>> from gmpy2 import mpq
>>> math.trunc(mpq(22, 7))

SymPy behaves similarly:

>>> from sympy import Rational
>>> type(math.trunc(Rational(22, 7)))
<class 'sympy.core.numbers.Integer'>

On the other side, there are conversions to integer that it doesn't make sense to think of as truncation. It would be odd for a UUID to be a valid input to math.trunc, for example:

>>> int(uuid.uuid4())
Date User Action Args
2021-08-22 15:56:51mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, serhiy.storchaka
2021-08-22 15:56:51mark.dickinsonsetmessageid: <>
2021-08-22 15:56:51mark.dickinsonlinkissue44977 messages
2021-08-22 15:56:51mark.dickinsoncreate