[Python-Dev] Re: decimal API

[Tim Peters]

I'm still of the opinion that the invalid-operation, overflow, and
division-by-zero traps should be enabled by default, and the others
disabled (the long list of conditions that's been given map
many-to-one onto the signals in the spec, and traps are associated
with signals, not with conditions; there are only 8 signals in the
spec)..

At KSR we built a (nearly) 754-conforming FPU, and our initial Fortran
and C compilers played along with the standard by disabling all traps
by default.  That lasted about a month.  Customers were rabidly
unhappy about it, and I sympathized.  Code that's *expecting* NaNs and
infinities can *sometimes* live gracefully with them, and more
gracefully with them than without them.  But like context itself, the
"non-stop" mode of running is aimed more at numeric experts than at
end users.  For example, library code can't allow an exception to
propagate to the caller when trying an expected-case optimization that
may overflow, and so setting "non-stop" mode is typical in library
routines.  The second releases of our compilers enabled the same set
of signals by default I'm recommending Python enable by default. 
Nobody complained about that, and very few users changed the defaults.
 When you find a setting that very few users change, that's the
natural setting to make the default.

[David Goodger]
> 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?

That was all done in pvt email.  Guido bounced it to me, and I said
"sure!".  The PEP is in as good a shape as the new-style class PEPs
when they were released, and Decimal will have more immediate benefits
for more users.  The PEP can still be edited after it's "final"
<wink>.