I was thinking about it yesterday. Perhaps a better solution would be dropping " or modulo" and leaving only "integer division by zero" for x / 0, x // 0 and divmod(x, 0). It does not make difference whether it is a true division, a floor division, or if the modulo is involved, -- it is all division by zero.

But if make the error message more specific (add "floor"), should not it also replace "division or modulo" with "division and modulo" for divmod(x, 0)?

Whatever be done for integers, should be done for other numerical types.

cc @mdickinson

I see the value in harmonising the error messages, but I suspect we're all going to have different opinions on what the message should be. I'd personally drop the mention of the type, so that both 10 // 0 and 10.0 // 0 would give message "floor division by zero". (And as a bonus, fractions.Fraction(10) // 0 would also give message floor division by zero, simply by propagating the error message from the internal integer division.)

So if we're changing this, I'd go for:

• 10 // 0, 10.0 // 0 - "floor division by zero"
• 10 / 0, 10.0 // 0 - "division by zero"
• 10 % 0, 10.0 % 0 is tricky: "modulo by zero" doesn't really work grammatically. But there's an implicit division, so "division by zero" doesn't seem wrong.

Would it be terrible to simply say "division by zero" for all these cases? No mention of type; no distinguishing between the /, //, % operators and divmod.

@serhiy-storchaka

Perhaps a better solution would be dropping " or modulo" and leaving only "integer division by zero" for x / 0, x // 0 and divmod(x, 0). It does not make difference whether it is a true division, a floor division, or if the modulo is involved, -- it is all division by zero.

+1

If it helps to harmonize the error messages, I support dropping also the type. The only difference may be if mixed types are involved, and the non-zero divisor is converted with losses to the zero of other type. But AFAIK there are no such cases in the core and the stdlib.

In the end, all ZeroDivisionError exceptions may have the same error message.

Ok, I agree. I will change my PR 👍

I think that I found one case that should not be changed:

>>> 0 ** -1
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    0 ** -1
    ~~^^~~~
ZeroDivisionError: 0.0 cannot be raised to a negative power

I would not want to see "division by zero" here. In fact, it will be just 1 / 0, but still it won't be very clear.

I also found that 0.0 is used when 0 ** -1

Agreed that the power case shouldn't be changed