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

[Michael Foord]

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).

Michael