Bug report

Bug description:

I'm seeing inconsistent failures in test_int's test_denial_of_service_prevented_str_to_int. Typical:

  File "C:\Code\Python\Lib\test\test_int.py", line 738, in test_denial_of_service_prevented_str_to_int
    self.assertLessEqual(sw_fail_extra_huge.seconds, sw_convert.seconds/2)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 0.015625 not less than or equal to 0.0078125

The displayed times are small enough that they're well within the range a non-idle Windows may, at times, essentially not give any cycles to a process.

I expect the underlying cause is that various hard-coded constants in the test were picked when CPython's int<->str conversions, for "large" values, were much slower than they are now. They're no longer quadratic-time. str->int is O(d**1.585) now (inherited from the asymptotics of CPython's Karatsuba multiplicatiom), and int->str the much better O(d * messy expression involving logarithms) (inherited from the asymptotics of _decimal's fancier NTT multiplication) - where d is the number of digits (or bits - same thing to O()).

Comments like:

        # Ensuring that we chose a slow enough conversion to measure.
        # It takes 0.1 seconds on a Zen based cloud VM in an opt build.

suggest a cure: don't use hard-coded constants. Instead take a starting guess at the number of digits and keep boosting it until a conversion actually does take 0.1 seconds.

Or don't bother timing it at all 😉. It's already checking that "big" cases raise ValueError with "conversion" in the exception detail message, so it's essentially certain that int() failed before doing any real work.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows