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

Tim Peters tim.peters at gmail.com
Tue Jul 6 23:16:43 CEST 2004

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" .

More information about the Python-Dev mailing list