Raymond, I think you've tricked yourself ;-)  The prototype for C's duoble modf is

double modf(double x, double *intptr);

Yes, after the call *intptr is an exact integer, but in the double format.

>>> math.modf(1e300)
(0.0, 1e+300)

I don't think it would be doing anyone a real favor by returning

1000000000000000052504760255204420248704468581108159154915854115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233794788090059368953234970799945081119038967640880074652742780142494579258788820056842838115669472196386865459400540160

instead of 1e300 for "the integer part".

`frexp()` is very different, in that the second part is a (small!) integer exponent - a float would work for that too, but would be surprising.

>>> math.frexp(1e300)
(0.7466108948025751, 997)

A better analogy would be to math.floor(), which does return an int, even for cases like floor(1e300).  In Python 2 it did not (it returned an integer but in float format), and I believe it was a mistake to change it to return an int.  Building giant ints is not what C does, so is surprising on that count alone, and is far more expensive than returning (as C does) a float.

That is, we didn't improve on C's floor, we introduced a surprising difference that sometimes hurts and rarely helps (if anyone really wanted an int, they could apply int() to the float result).