[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Changes by Raymond Hettinger : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Stefan Krah added the comment: I agree that it might add confusion. In the C-module,I currently do this: >>> Decimal(0) / 0 Traceback (most recent call last): File "", line 1, in cdecimal.InvalidOperation: [] But since you already have a detailed error message, this doesn't seem necessary

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson added the comment: 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: >>> pri

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Stefan Krah added the comment: 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, s

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Changes by Mark Dickinson : -- assignee: -> mark.dickinson priority: -> normal stage: -> needs patch type: -> behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker ___

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson added the comment: 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 excep

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson added the comment: 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 sp

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

New submission from Stefan Krah : 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 d