The int/long unification occurred a long time ago. ("long" was Python's name for BigNum.) There is now no such thing as "exceed the bounds of its provided integer types".
Guido van Rossum, who started and lead the Python project for many years, previously worked with ABC, which used rational as the default type. In practice this caused problems as it was all to easy to end up with "pathologically large numerators and denominators" (quoting https://docs.raku.org/type/FatRat). That experience guided him to reject rationals as the default integer type.
Pathologically large numerators and denominators make rationals not "just slower" but "a lot slower".
> somehow every Python implementation would be compatible
It's more of a rough consensus thing than full compatibility.
> Python doesn't really care about compatibility
Correct, and it causes me pain every years. But do note that historic compatibility is different than cross-implementation compatibility, since there is a strong incentive for other implementations to do a good job of staying CPython compatible.
FWIW, the laptop where I did my timings is 5 years old.
The new programmers in my field generally have Python as their first language, and don't have experience with float32.
I also know that float32 isn't enough to distinguish rationals I need to deal with, since in float32, 2094/4097 == 2117/4142 == 0.511106, while in float64 those ratios are not equal, as 0.5111056870881132 != 0.5111057460164172.
(I internally use uint16_t for the ratios, but have to turn them into doubles for use by other tools.)
sum() of a list with 100M floats took 0.65 seconds. The explicit loop took 1.5 seconds on CPython 3.13.
But again, yes, Rust performance runs rings around CPython, but that's not enough to justify switching to an alternative numeric type given the many negatives, and Python's performance isn't as dire as you suggest.
Guido van Rossum, who started and lead the Python project for many years, previously worked with ABC, which used rational as the default type. In practice this caused problems as it was all to easy to end up with "pathologically large numerators and denominators" (quoting https://docs.raku.org/type/FatRat). That experience guided him to reject rationals as the default integer type.
Pathologically large numerators and denominators make rationals not "just slower" but "a lot slower".
> somehow every Python implementation would be compatible
It's more of a rough consensus thing than full compatibility.
> Python doesn't really care about compatibility
Correct, and it causes me pain every years. But do note that historic compatibility is different than cross-implementation compatibility, since there is a strong incentive for other implementations to do a good job of staying CPython compatible.
FWIW, the laptop where I did my timings is 5 years old.
The new programmers in my field generally have Python as their first language, and don't have experience with float32.
I also know that float32 isn't enough to distinguish rationals I need to deal with, since in float32, 2094/4097 == 2117/4142 == 0.511106, while in float64 those ratios are not equal, as 0.5111056870881132 != 0.5111057460164172.
(I internally use uint16_t for the ratios, but have to turn them into doubles for use by other tools.)