In fact, this case is also suitable for mod.

Maybe it could be fixed on this way...

diff --git a/Lib/fractions.py b/Lib/fractions.py
index c95db0730e..fe3a5d137b 100644
--- a/Lib/fractions.py
+++ b/Lib/fractions.py
@@ -611,16 +611,18 @@ class doesn't subclass a concrete type, there's no
 
         """
         def forward(a, b):
-            if isinstance(b, Fraction):
-                return monomorphic_operator(a, b)
-            elif isinstance(b, int):
-                return monomorphic_operator(a, Fraction(b))
-            elif isinstance(b, float):
-                return fallback_operator(float(a), b)
-            elif isinstance(b, complex):
-                return fallback_operator(complex(a), b)
-            else:
-                return NotImplemented
+            try:
+                if isinstance(b, Fraction):
+                    return monomorphic_operator(a, b)
+                elif isinstance(b, int):
+                    return monomorphic_operator(a, Fraction(b))
+                elif isinstance(b, float):
+                    return fallback_operator(float(a), b)
+                elif isinstance(b, complex):
+                    return fallback_operator(complex(a), b)
+            except TypeError:
+                pass
+            return NotImplemented
         forward.__name__ = '__' + fallback_operator.__name__ + '__'
         forward.__doc__ = monomorphic_operator.__doc__
 

(Ditto for the reverse().)

Here is a traceback:

>>> fractions.Fraction(1,2)//1j
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for //: 'Fraction' and 'complex'

Thanks!
Thats looking more pythonic, and this solves the problem, btw, tests are green. I'll send a PR.

As a rule we don't do type checking like this. Is the original traceback really that confusing?

Docs/fractions say nothing about convert Fraction to complex.
For new user, traceback which says that floordiv cannot be applied between two complex, really confusing.
User try to floordiv Fraction and complex, but in traceback he saw a two complex objects.
IMO

Yes, but the code in the traceback shows that it's converting one argument to complex, so that explains one of them. But maybe I overestimate what people can figure out from the traceback.

Assessment of what can be understood by humans within traceback - really hard and subjective thing, so I can't say anything about this at all.
However, PR which related with this issue, doesn't break backward compatibility, just make prettier traceback, I think, we should take in account that.

@ericvsmith: "As a rule we don't do type checking like this. " We already are doing 'this' as the proposal just wraps an existing isinstance chain in try: except. I definitely like the revised message better.

@terryjreedy: Thanks. I was trying to get across that in general we don't try to improve messages where duck typing fails.

But you're correct, in this case we are already dispatching based on the type of a parameter, so my argument is weak. I think the better solution here might be to not try to convert the numerator to a complex value, since we know that a_complex // b_complex isn't going to work. But that would require some surgery to make // a special case, different from say a_complex * a_float.

I'm not convinced that this is worth the effort; it seems like an unlikely case to even hit in the first place.

I would like to backport this change (the final version), but other coredevs were skeptical. Confusing error message is not a large bug.