In many cases, decimal.py sets InvalidOperation instead of
DivisionImpossible or DivisionUndefined.

Mark, could I persuade you to isolate these cases by running a modified
deccheck2.py from mpdecimal (See attachment), which does not suppress
differences in the division functions?

Just to be clear, the decimal context doesn't (and shouldn't) know about DivisionImpossible:  there's 
no DivisionImpossible signal or trap described in the specification, but just a DivisionImpossible 
heading in the 'exceptional conditions' section of the spec.  And that DivisionImpossible condition 
signals InvalidOperation (according to the spec).  (And similarly for DivisionUndefined.)

So I don't think decimal.py is in violation of the specification here.

But decimal.py could be changed so that a call to _raise_error(context, DivisionImpossible, ...)
results in the DivisionImpossible exception being raised instead of the InvalidOperation exception.
This shouldn't break anything, since DivisionImpossible is a subclass of InvalidOperation.

Note that the appropriate sections of decimal.py do already raise the right conditions (unless some 
have been missed):  e.g., in Decimal._divide, we have the lines:

    # Here the quotient is too large to be representable                                                                                                                                              
    ans = context._raise_error(DivisionImpossible,
                               'quotient too large in //, % or divmod')

But the Context._raise_error method currently translates all the exceptional conditions to their 
corresponding signals, hence raises InvalidOperation in this case.

Closed issue 7047 as a duplicate of this one:  
_raise_error(ConversionSyntax) also raises (if trapped) the 
InvalidOperation exception, when it could reasonably raise 
ConversionSyntax instead.  It's the same cause as above:  _raise_error 
translates each exceptional condition to the corresponding signal.

Thanks for the explanation, and I agree that decimal.py is perfectly
correct. I based the report on the fact that decNumber updates the
context status with e.g. Division_impossible. But Division_impossible is
one of the flags that form IEEE_754_Invalid_operation, so presumably the
intention is to signal IEEE_754_Invalid_operation by means of flagging
Division_impossible.

On a side note, I find the distinction between signals and exceptional
conditions (mandated by the spec, as you pointed out) needlessly
complicated and I'm happy to see that note 5 under "Abstract
representation of context" says this might change in the future.

I'm all for raising DivisionImpossible, if it is not too much trouble.

I think it's actually easier for the user if we keep the exception type 
as it is, so that it's clear which flag it corresponds to.  This didn't 
occur to me until I looked at the section of the doctests (around line 
100 in decimal.py) that looks like:

>>> print c.divide(Decimal(0), Decimal(0))
Traceback (most recent call last):
  ...
  ...
  ...
InvalidOperation: 0 / 0
>>> print c.flags[InvalidOperation]
1

If the traceback specified 'DivisionUndefined' instead then the user has 
to figure out that the corresponding flag/trap is InvalidOperation.

Of course this could be worked around by giving a more detailed error 
message, e.g. DivisionUndefined: (InvalidOperation) 0/0, but this 
doesn't seem worth changing to me.

I agree that it might add confusion. In the C-module,I currently
do this:

>>> Decimal(0) / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
cdecimal.InvalidOperation: [<class 'cdecimal.DivisionUndefined'>]


But since you already have a detailed error message, this doesn't
seem necessary for decimal.py.

Close this one?