I propose that we add 'of ####' to all ZeroDivisionError messagesso it is less necessary to use a debugger to add print statements to recover the information currently tossed away. (I also propose to change denominator from 'zero' to '0', '0.0', '0+0j', as appropriate.) 

>>> 3//0
...
ZeroDivisionError: integer division or modulo by zero

# augment to
ZeroDivisionError: integer division or modulo of 3 by 0

Similarly for

>>> 3 / 0
ZeroDivisionError: division by zero

# perhaps this should be 'true division of 3 by 0'

>>> 3.0 / 0.0
ZeroDivisionError: float division by zero

>>> (3+3j) / (0+0j)
ZeroDivisionError: complex division by zero

In #7482 it was proposed to make float and complex messages same as int message by adding 'or modulo'. I an not sure why not to do that, or if it was just deferred.

Fractions currently print the numerator as part of an invalid numerator / 0 result from *either* construction or division.

>>> from fractions import Fraction as F
>>> F(3, 0)
Traceback (most recent call last):
  File "<pyshell#20>", line 1, in <module>
    F(3, 0)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
    raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid input.

>>> F(3, 1) / F(0, 1)
Traceback (most recent call last):
  File "<pyshell#19>", line 1, in <module>
    F(3, 1) / F(0, 1)
  File "C:\Programs\Python33\lib\fractions.py", line 367, in forward
    return monomorphic_operator(a, b)
  File "C:\Programs\Python33\lib\fractions.py", line 417, in _div
    a.denominator * b.numerator)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
    raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid output.
I found this confusing until I worked out the dual meaning. I think

ZeroDevisionError: invalid Fraction(3, 0) from construction or division

might be a bit clearer.

I have not looked at decimals.

What would be the point? Usually you should find out why the denominator is zero, not what the numerator's value is.

In case the value of the numerator helps find out why the denominator is 0. The example given by Mike Graham on python-ideas, Verbose traceback formatting was

def f(a):
    x = a * 4
    y = a - 4
    return x / y

> In case the value of the numerator helps find out why the denominator
> is 0. The example given by Mike Graham on python-ideas, Verbose
> traceback formatting was
> 
> def f(a):
>     x = a * 4
>     y = a - 4
>     return x / y

Well, in this case y == 0 iff a == 4. I don't see how the numerator
helps at all.
(and besides, it's a rather silly artificial example)

I'm not sure this is really useful.  Once I know that I divided by zero and I know where the division is, I don't really care what the numerator is.  Knowing the exact type of the denominator (0, 0.0, 0j) doesn't sound too useful as well -- unless you somehow manage to get the wrong type and a 0-value at the same time.

On a side note, I don't like
ZeroDivisionError: integer division or modulo of 3 by 0
too much, but I would prefer
ZeroDivisionError: integer division (or modulo) by zero
over
ZeroDivisionError: integer division or modulo by zero

IIRC the reason why both "division" and "modulo" are included in the message is because the error is created in a piece of code that is shared by both operations.

Terry, do you still think that adding the numerator would be useful?

I'll add my -1 to this;  I don't really see the use.

Not enough, at present, to leave this open.