[Python-Dev] RE: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58

[Guido van Rossum]

[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/)