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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4