But, here a one problem - would be nice to have in traceback originally // instead of floordiv. I have no idea how to do it, without create a mapping with names. Theoretically - we can add a special attribute for it in operator, but it should be a another discussion.
changed the title [-]Confused traceback while floor division happens between `Fraction` and `complex` objects[/-][+]Confused traceback while `floordiv` or `mod` happens between `Fraction` and `complex` objects[/+]on Mar 20, 2023
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.
Activity
Eclips4 commented on Mar 20, 2023
In fact, this case is also suitable for mod.
skirpichev commented on Mar 20, 2023
Maybe it could be fixed on this way...
(Ditto for the reverse().)
Here is a traceback:
Eclips4 commented on Mar 20, 2023
Thanks!
Thats looking more pythonic, and this solves the problem, btw, tests are green. I'll send a PR.
ericvsmith commented on Mar 20, 2023
As a rule we don't do type checking like this. Is the original traceback really that confusing?
Eclips4 commented on Mar 20, 2023
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
ericvsmith commented on Mar 20, 2023
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.
Eclips4 commented on Mar 20, 2023
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.
terryjreedy commented on Mar 20, 2023
@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.
ericvsmith commented on Mar 21, 2023
@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.
mdickinson commented on Mar 22, 2023
I'm not convinced that this is worth the effort; it seems like an unlikely case to even hit in the first place.
gh-102840: Fix confused traceback when floordiv or mod operations hap…
serhiy-storchaka commented on Feb 10, 2024
I would like to backport this change (the final version), but other coredevs were skeptical. Confusing error message is not a large bug.
pythongh-102840: Fix confused traceback when floordiv or mod operatio…