Acccording to: https://docs.python.org/3/library/functions.html#float

>    If the argument is outside the range of a Python float, an OverflowError will be raised.

It is well known that the maximum value in IEEE 754 binary64 format is:

    >>> M = ((1<<53)-1)<<(1023-52)
    ...

So `(M+1)` will be out of range. But `float(M+1)` gives me:

    >>> float(M+1)
    1.7976931348623157e+308

No OverflowError is thrown. Contrast this with:

    >>> float(M+M)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: int too large to convert to float

In another text: https://docs.python.org/3/tutorial/floatingpoint.html#representation-error

>   ...Almost all machines today (November 2000) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 “double precision”...

Is Python not following IEEE 754 binary64 format or something missing here?

float(x) performs rounding. Only if the value after rounding is out of range is OverflowError raised.

M + 1, when correctly rounded to the nearest even float, gives sys.float_info.max. Likewise for M+2, M+3 etc all the way to M+K where K equals 2**960 before the correctly rounded result of float(M+K) overflows.

Anything less than K=2**960 is too small to be distinguished from M when added to it. So there's no bug here, the behaviour is correct for IEEE-754, although perhaps the documentation is misleading.

Mark, is my explanation right?

If python's float strictly adheres to IEEE 754 binary64 (is that so?), then the problem may be caused by rounding. However, even in that case I still don't get the benefits of doing range check on a rounded input but not the input itself. Does IEEE 754 itself give any specifications about range check and rounding during such type conversion?

IEEE 754, 7.4 Overflow:

>   The overflow exception shall be signaled if and only if the destination format’s largest finite number is exceeded in magnitude by what would have been the rounded floating-point result (see 4) were the exponent range unbounded...

Were this the basis of the float implementation, not raising an overflow exception seems to be the correct behavior? Then this is not a bug, but the python float doc might better say "If the *rounded* argument is outside..."

Yes, exactly: Python's intentionally following the normal IEEE 754 rules for rounding a value to the binary64 format using the round-ties-to-even rounding rule, as formalised in section 7.4 of IEEE 754-2019 (and quoted by @cykerway). These are the exact same rules that are followed for conversion from str to float (where we return `inf` rather than raise `OverflowError` for large values, but the overflow boundary is the same), or conversion from Fraction to float, or conversion from Decimal to float, etc.

> the python float doc might better say "If the *rounded* argument is outside..."

Docs are hard. I think there's a danger that that word "rounded" would cause more confusion than it alleviates - to me, it suggests that there's some kind of rounding going on *before* conversion to float, rather than *as part of* the conversion to float. This isn't a language specification document, so it's not reasonable to give a perfectly accurate description of what happens - the actual meaning would be lost in the mass of details. (In this case, it would also be rather hard to be precise, given that we have to allow for platforms that aren't using IEEE 754.) I'm not seeing an obvious way to improve the docs here.

If we wanted to make a change, I think the part of the docs that I'd target would be this sentence:

> a floating point number with the same value (within Python’s floating point precision) is returned

It's that "same value (within Python's floating point precision)" bit that I'd consider changing. We could consider replacing it with something along the lines that "an integer argument is rounded to the nearest float", possibly with an additional note that under the assumption of IEEE 754 binary64 format, we follow the usual IEEE 754 rules.

Alright that helps. I guess I now understand what's happening here. Here are the two numbers in question:

>>> M = int('1'*53+'0'*971, 2)
>>> N = int('1'*53+'0'+'1'*970, 2)

M is the largest number in binary64 range, while N is the largest number that does not emit an OverflowError when converted to binary64. N+1 will emit that error. N-M == 2**970-1 which means N is larger than M that caused the confusion.

Changing to a documentation issue.

I think the documentation reads better as it currently is. Does this really cause any practical confusion?

As Mark notes, we can't specify things exactly here: that would obfuscate all of the things we're actually trying to say.