Raymond Hettinger 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? >
If the ambiguity is that 'int' behaviour is unspecified for floats - is it naive to suggest we specify the behaviour? Michael Foord > > Raymond > _______________________________________________ > 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/fuzzyman%40voidspace.org.uk > > _______________________________________________ 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