Mark Dickinson <dicki...@gmail.com> added the comment: One issue occurs to me: should the backport change the behaviour of the round function?
In py3k, round consistently uses round-half-to-even for halfway cases. In trunk, round semi-consistently uses round-half-away-from-zero (and this is documented). E.g., round(1.25, 1) will give 1.2 in py3k and (usually) 1.3 in trunk. I definitely want to use Gay's code for round in 2.7, since having round work sensibly is part of the motivation for the backport in the first place. But this naturally leads to a round-half-to-even version of round, since the Python-adapted version of Gay's code isn't capable of doing anything other than round-half-to-even at the moment. Options: (1) change round in 2.7 to do round-half-to-even. This is easy, natural, and means that round will agree with float formatting (which does round-half-to-even in both py3k and trunk). But it may break existing applications. However: (a) those applications would need fixing anyway to work with py3k, and (b) I have little sympathy for people depending on behaviour of rounding of *binary* floats for halfway *decimal* cases. (Decimal is another matter, of course: there it's perfectly reasonable to expect guaranteed rounding behaviour.) It's more complicated than that, though, since if rounding becomes round-half-to-even for floats, it should also change for integers, Fractions, etc. (2) have round stick with round-half-away-from-zero. This may be awkward to implement (though I have some half-formed ideas about how to make it work), and would lead to round occasionally not agreeing with float formatting. For example: >>> '{0:.1f}'.format(1.25) '1.2' >>> round(1.25, 1) 1.3 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7117> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com