[Python-Dev] RE: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58 (original) (raw)
Guido van Rossum guido@python.org
Mon, 15 Apr 2002 20:10:28 -0400
- Previous message: [Python-Dev] RE: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58
- Next message: [Python-Dev] Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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 . 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/)
- Previous message: [Python-Dev] RE: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58
- Next message: [Python-Dev] Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]