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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4