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