[Python-Dev] Re: decimal API

[David Goodger]

Raymond Hettinger wrote:
 > For the alpha, I've left all of the traps off except for
 > ConversionSyntax.

I agree with Michael Chermside list of traps that should be on by
default.  As a potential user of Decimal, I'd much rather start off
with training wheels *on*.  I can always take them off myself later.

Going back to Tim Peters' post from a few days ago,

Tim Peters wrote:
 > Note that I've suggested that some trap-enable flags should be set
 > by default for Python: those for invalid operation, divide by 0, and
 > overflow.
...
 > That's one reason I want Python to enable the invalid-operation trap
 > by default.  That choice isn't suitable for all apps all the time,
 > but I have no hesitation Pronouncing that it will be suitable for
 > most Python apps most of the time.

Tim also wrote, "Errors should never pass silently, unless explicitly
silenced."  I put high value on Tim's opinions in matters
mathematical, and so does Guido: he delegated to Tim on PEP 327.

That brings up a point: although marked "Final" in CVS, I never saw an
official "Accepted" pronouncement from Tim or Guido.  So, just for the
record,

Tim, do you agree that PEP 327 should be marked Accepted & Final?

Michael Chermside wrote:
 > 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!

Tim, do you agree with this list?  Any changes?

I think the decision of which signals to trap (convert to Python
raised exceptions) should be added to the PEP.

(Hmmm.  There seems to be a mismatch between the PEP and the
implementation.  The "signals" listed above are listed as "conditions"
in the PEP, and according to the PEP, the "invalid-operation" signal
covers several conditions: conversion syntax, division impossible &
undefined, invalid context, and invalid operation.  See
<http://www.python.org/peps/pep-0327.html#exceptional-conditions>.)

-- 
David Goodger                    <http://starship.python.net/~goodger>
Python Enhancement Proposal (PEP) Editor <http://www.python.org/peps/>