[Python-Dev] decimal API

[mcherm2 at mcherm.com]

Raymond writes:
> For the alpha, I've left all of the traps off except for
> ConversionSyntax.  The reasoning that the numeric model is otherwise
> self-contained.  Dividing by zero usefully gives Infinity.
> NaNs result
> from non-sensical operations.  NaNs can even have diagnositic
> information associated with them.  Let's let people
> experience what the
> standard has to offer.
    [...]
> Though decimals play nice with many other Python tools, we shouldn't
> hide that the model is different and that many of those
> differences are
> for the better:

I guess I'm -0.5 on this... I object, but not strongly. I WILL
go ahead and express my reasons for objecting, but if you don't
find them convincing, then go ahead as planned and I won't complain.

Your list of ways that Decimal's model is better is an excellent
list, but much of it doesn't apply to the question of whether the
traps should default to on or off. I'll admit that the feature

  > - Special values such as NaNs and Infinities

is "invisible" if we turn on my prefered list of traps because
you can't create a NaN or an Infinity. Obviously, the traps can
easily be turned off, but that doesn't negate the fact that
people will be more aware that Decimal supports NaN and Infinity
if they get NaNs and Infinities while playing interactively.

The feature:

  > - Signals can be ignored, inspected (flag), or raised (trapped)

is pretty much a wash... if we turn traps ON people will have to
read the docs to realize that signals can be ignored (and inspected
after), and if we turn them OFF they'll have to read to realize
that signals can RAISE.

The other features:

  > - Calculations taking place within a user settable context
  > - Negative zero
  > - Notion of significance:   1.25 + 1.75 --> 3.00 with two trailing
  > zeroes

are all visible whether traps default to ON or OFF.

So in the end, we're talking about what we want to do for people
who choose NOT to read the docs. And I submit that we want
those people to get an exception, because when they try to do
their task and they get an exception instead, they will then
turn to the docs to decide how to fix it. But if we left traps
OFF then these foolish people might see that their program had
run to completion and then accept the results without even
realizing that there was a way to check for signals.

-- Michael Chermide