[Python-Dev] decimal API (original) (raw)

mcherm2 at mcherm.com mcherm2 at mcherm.com
Tue Jul 6 18:20:37 CEST 2004

Facundo writes:

I'm +1 to enable some by default: DivisionByZero, DivisionUndefined, Overflow, InvalidOperation, ConversionSyntax and DivisionImpossible are my proposal, but it's my taste and know nothing about numbers usability...

Here are my thoughts, just as untutored as yours. I'm working primarily from hursley's spec here...

Signal Should it raise by default? And why?

Clamped Yes - well, maybe. When could we ever generate this? ConversionSyntax Yes - it prevents lots of possible user errors DivisionByZero Yes - other numeric types raise for this in Python DivisionImpossible Yes - I don't fully understand it but it seems bad DivisionUndefined Yes - other numeric types raise for this in Python Inexact No - this is perfectly normal InsufficientStorage N/A - this doesn't exist in the Python implementation InvalidContext Yes - I don't understand how this could happen, but surely we should complain about it, right? InvalidOperation Yes - Users want exceptions when doing invalid math Overflow Yes - overflows lose data, so we should raise Rounded No - this is perfectly normal Subnormal No - this is perfectly normal (subnormal?) Underflow No - since Inexact, Rounded, and Subnormal are all unreported, this should be also!

Then there are these, which I don't recognize: DecimalException, LostDigits

To sum things up, I would suggest that by default errors should never pass silently, and that "errors" is defined as broadly as possible without triggering on normal arithmatic. Obviously, it's easy to change the settings, but it's much easier to DISABLE an exception when your program starts generating it, than to ENABLE it, because if it's disabled, you don't necessarily know that it is happening. Besides, it seems Pythonic to be pedantic.

-- Michael Chermside

More information about the Python-Dev mailing list