Thanks@serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

GH-119255 is a backport of this pull request to the3.13 branch.

GH-119256 is a backport of this pull request to the3.12 branch.

I noticed that the newly added tests are written the wrong way around. When a test fails, it says something like

Traceback (most recent call last):  File "test_fractions.py", line …, in testMixedDivision    self.assertTypedEquals(F(3, 2) / Rat(3, 5), Rat(15, 6))  File "test_fractions.py", line …, in assertTypedEquals    self.assertEqual(type(expected), type(actual))AssertionError: <class 'Fraction'> != <class '__main__.Rat'>

Note howexpected andactual are reversed here. This is misleading and it took me a couple of looks to understand that I was simply searching for the wrong kind of bug. The previously existing tests were apparently written the other way round:

        self.assertTypedEquals(F(1, 10), F(1, 10) / 1)  # existing

versus

        self.assertTypedEquals(F(3, 2) / DummyFraction(3, 5), F(5, 2))  # new

The normal order for assertEqual() is actual, expected. But some old tests are written with other order. We do not touch them to avoid code churn. It seems that old tests here were written in such order, but assertTy po edEquals then reverted the order .