Stefan Krah added the comment:
I guess there's not much to be done here.
--
resolution: - wont fix
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
Stefan Krah added the comment:
It is hard to get fine grained error messages in _decimal, since
the errors come from libmpdec. A clean solution would require
changes to libmpdec, and I'm reluctant to do that right now.
It is certainly possible to document DivisionImpossible etc.
--
Stefan Krah added the comment:
Meanwhile, the pure Python decimal versions prior to Python 3.2
have better error messages.
Right now in Python 3.3+ it is hard to import the Python version
without going into contortions, but that may be fixed in #19232.
--
dependencies: +Speed up
leewz added the comment:
Fine grained? Do you mean that the error can't be distinguished from other such
errors? Or that it's difficult to attach the message to DivisionError? I
thought DivisionError was always about precision.
I looked up the error in libmpdec:
This occurs and signals
Stefan Krah added the comment:
My apologies if that wasn't clear: fine grained refers to the exception
messages. A function can raise InvalidOperation for different reasons.
decimal.py gives a specific error message in each case. libmpdec just
signals the standard conforming InvalidOperation.
leewz added the comment:
Nah. I found it surprising at first, but like I said, it's like the computer is
given the first 28 digits of a number and then asked to figure out the 30th
digit.
What I'm confused about is how it fits the definition of division impossible
given by libmpdec's docs
Stefan Krah added the comment:
In the case of DivisionImpossible it would actually be possible to use
the error message 'quotient too large in //, % or divmod'.
But that's just one condition. In the case of InvalidOperation there
are something like 30 different error messages.
--
Raymond Hettinger added the comment:
It is certainly possible to document DivisionImpossible etc.
This should not be done. We've made strong efforts to not extend the Decimal
Arithmetic Specification.
Also, the API already suffers from high complexity. Adding more exceptions to
the mix
Stefan Krah added the comment:
Raymond Hettinger rep...@bugs.python.org wrote:
It is certainly possible to document DivisionImpossible etc.
This should not be done. We've made strong efforts to not extend the Decimal
Arithmetic Specification.
The exceptions are already there:
Python
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
___
leewz added the comment:
Total list of issues now:
- Error message for `DivisionImpossible` is
[class 'decimal.DivisionImpossible']
instead of an actual error message.
- `decimal.DivisionImpossible.__doc__` is empty.
- Calling `help(decimal.DivisionImpossible)` turns up nothing useful.
Stefan Krah added the comment:
leewz rep...@bugs.python.org wrote:
- Error message for `DivisionImpossible` is
[class 'decimal.DivisionImpossible']
instead of an actual error message.
No, the error message for the *signal* that is raised (InvalidOperation) lists
the *condition* that
Stefan Krah added the comment:
The idea behind the list as the exception message is this: If multiple
conditions would have raised the signal they are all listed, while the
highest ranking signal is the one that is ultimately raised.
from decimal import *
c = getcontext()
for v in c.traps:
Changes by Stefan Krah stefan-use...@bytereef.org:
--
assignee: docs@python - skrah
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21227
___
New submission from leewz:
Python's `decimal.Decimal` doesn't seem to like taking modulo or intdiv of
large Decimals by integers (where large depends on how many digits are
internally stored).
from decimal import *
getcontext().prec
28
Decimal(10**29)%1
Traceback (most
15 matches
Mail list logo
