[Python-Dev] [python] Re: trunc()

Guido van Rossum guido at python.org
Fri Jan 25 00:44:58 CET 2008


On Jan 24, 2008 3:32 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
> Jeffrey Yasskin wrote:
> > 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.
> >
> >
> So you won't be able to construct an int from a float? That sucks (and
> is unintuitive).

Yes, you can, but you have to specify how you want it done by using
trunc() or round() or ceil() or floor(). (In 3.0, round(x) will return
an int, not a float.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list