[me] > > But if the end result is that users will write trunc() or round() > > calls whenever they have a float value that they believe is an int > > and that they want to use in an int context -- but then when it's > > not even close to an int, they won't notice. [Tim] > I was wondering when someone would get to that <wink>. Implicit in > that complaint is that, if we left magical float->int up to "the > system", then the system could benevolently decide when a given > float was or wasn't "close enough" to an exact int to make no > difference. Can I raise a ChannelingError? That was not at all where my thoughts went (I know better than that). If I was going anywhere, it was against unified numbers, period. [...] > Common Lisp says "screw that -- if you think this is usable as an > int, you convert it to an int yourself: your choice, your > responsibility, and here are 4 convenient functions for choosing the > rounding you want". I just hope there's something more refined than round() and trunc(), so that I can easily apply my *own* fuzz. Maybe round(x, n) could return an int when the result is an int (which for round(x, n) is well-defined unless x or n is very large). --Guido van Rossum (home page: http://www.python.org/~guido/)
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