Mark Dickinson <dicki...@gmail.com> 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 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7046>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
