Message95789
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. |
|
Date |
User |
Action |
Args |
2009-11-28 15:36:20 | mark.dickinson | set | recipients:
+ mark.dickinson, skrah |
2009-11-28 15:36:20 | mark.dickinson | set | messageid: <1259422580.67.0.791900725863.issue7046@psf.upfronthosting.co.za> |
2009-11-28 15:36:19 | mark.dickinson | link | issue7046 messages |
2009-11-28 15:36:18 | mark.dickinson | create | |
|