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

David Goodger goodger at python.org
Tue Jul 6 22:02:48 CEST 2004

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/>

More information about the Python-Dev mailing list