gh-119189: Add more tests for mixed Fraction arithmetic

[serhiy-storchaka]

• Issue: Fraction wrongfully gets casted into float when given as argument to __rpow__ #119189

[mdickinson]

LGTM; two nitpick-level comments.

[miss-islington-app]

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

[bedevere-app]

GH-119255 is a backport of this pull request to the 3.13 branch.

[bedevere-app]

GH-119256 is a backport of this pull request to the 3.12 branch.

[scoder]

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 how expected and actual 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

[serhiy-storchaka]

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 .