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

Michael Foord fuzzyman at voidspace.org.uk
Fri Jan 25 00:32:07 CET 2008

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

More information about the Python-Dev mailing list