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. -- Namasté, Jeffrey Yasskin _______________________________________________ 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