homepage

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