Jeffrey Yasskin wrote: > On Jan 24, 2008 1:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
