[Python-Dev] trunc()

[Jeffrey Yasskin]

On Jan 24, 2008 1:11 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Raymond Hettinger]
> > Since something similar is happening to math.ceil and math.floor,
> > I'm curious why trunc() ended-up in builtins instead of the math
> > module.  Doesn't it make sense to collect similar functions
> > with similar signatures in the same place?
>
> [Christian Heimes]
> > Traditionally the math module is a tiny wrapper around the
> > system's libm. Functions for magic hooks like __trunc__
> > usually end up in builtins. In this particular case I don't
> > mind where the function is going to live.
>
> Traditions have gone out the window.  ceil() and floor()
> are going to have their signatures changed (Real --> Integral)
> and are going to have their own magic methods.  They cannot
> be characterized as a thin wrapper around libm.
>
> So the question stands, why is trunc() different?  Can anything
> good come from having trunc() and int() in the same namespace?

One of my goals for trunc() is to replace the from-float use of int(),
even though we can't remove it for backward-compatibility reasons. PEP
3141 says:

  "Because the int() conversion implemented by float (and by
decimal.Decimal) is equivalent to but less explicit than trunc(),
let's remove it. (Or, if that breaks too much, just add a deprecation
warning.)"

That needs to be updated and implemented. I think the decision was
that removing float.__int__() would break too much, so it needs a
deprecation warning in 3.0.

int has to be a builtin because it's a fundamental type. trunc()
followed round() into the builtins. I have no opinion on whether ceil
and floor should move there; it probably depends on how often they're
used.

-- 
Namasté,
Jeffrey Yasskin