This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients eric.smith, mark.dickinson, rhettinger
Date 2009-10-24.18:15:38
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
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.


(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)
    >>> round(1.25, 1)
Date User Action Args
2009-10-24 18:15:43mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, eric.smith
2009-10-24 18:15:42mark.dickinsonsetmessageid: <>
2009-10-24 18:15:40mark.dickinsonlinkissue7117 messages
2009-10-24 18:15:39mark.dickinsoncreate