Mark Dickinson <[EMAIL PROTECTED]> added the comment: For what it's worth, I'm -0.1 (or should that be -0.10000000000000001?) on this change. It seems better to leave the problems caused by binary floating-point out in the open than try to partially hide them, and the proposed change just seems a little bit too 'magic'. The inconsistency in the following current behaviour *does* irk me slightly (but only slightly):
>>> 0.13 0.13 >>> 0.14 0.14000000000000001 But practical issues aside, my preference would be to go to the other extreme: fix this inconsistency by changing the first output to 0.13000000000000000 rather than changing the second output to 0.14. That is, have repr(float) *always* output 17 digits, possibly except when that float is *exactly* representable in 16 or fewer decimal digits (e.g. 3.5, 0.125, ...). All the zeros act as a subtle reminder that the stored value is not exactly 0.13. But I suspect this, too, isn't very practical. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
