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 tim.peters
Recipients Serge Anuchin, mark.dickinson, pitrou, r.david.murray, rhettinger, serhiy.storchaka, skrah, steven.daprano, tim.peters, vstinner
Date 2015-07-12.00:58:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1436662684.63.0.346728656346.issue24567@psf.upfronthosting.co.za>
In-reply-to
Content
[Raymond]
> I can't say that I feel good about making everyone pay
> a price for a problem that almost no one ever has.

As far as I know, nobody has ever had the problem.  But if we know a bug exists, I think it's at best highly dubious to wait for a poor user to get bitten by it.  Our bugs aren't their fault, and we have no idea in advance how much our bugs may cost them.

Note that there's no need to change anything on boxes without double-rounding, and those appear to be the majority of platforms now, and "should" eventually become all platforms as people migrate to 64-bit platforms.  So, e.g.,

    if double_rounding_happens_on_this_box:
        def choice(...):
            # fiddled code
    else:
        def choice(...):
            # current code just indented a level

Then most platforms pay nothing beyond a single import-time test.  Note that there's already code to detect double-rounding in test_math.py, but in that context not to _fix_ a problem but to ignore fsum() tests that fail in its presence.

And just to be annoying ;-) , here's another timing variation:

    i = int(random() * n)
    return seq[i - (i == n)]
History
Date User Action Args
2015-07-12 00:58:04tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, pitrou, vstinner, steven.daprano, r.david.murray, skrah, serhiy.storchaka, Serge Anuchin
2015-07-12 00:58:04tim.peterssetmessageid: <1436662684.63.0.346728656346.issue24567@psf.upfronthosting.co.za>
2015-07-12 00:58:04tim.peterslinkissue24567 messages
2015-07-12 00:58:03tim.peterscreate