[Python-Dev] decimal.py signals & traps

Tim Peters tim.peters at gmail.com
Thu Jul 8 04:40:43 CEST 2004


[David Goodger]
...
> Should traps be set on spec/PEP conditions, or spec/PEP signals?

On signals, not on conditions.  The 8 signals in the spec are listed
near the end of

    http://www2.hursley.ibm.com/decimal/damodel.html

Context must contain one sticky-flag and one trap-enable flag for each
signal.  If we're providing more than just that, we're extending the
standard, which probably wasn't intended.

I'll add that the spec's use of "conditions" grouped (many-to-one)
*into* signals seems unnecessary and confusing.

OTOH, I believe the spec isn't complete yet either.  What's normal for
"a spec like this" is to go on to specify information that must be
provided to a trap handler when one is invoked.  In Python, that would
presumably be implemented by setting attribute values on the exception
object.  That would be a natural way for a trap handler to learn which
condition was the cause of the trapped signal.  Or we could define an
exception for each condition, and subclass from the 8 signal
exceptions appropriately.

For example, the 754 standard requires that when a double-precision
overflow is trapped, the trap handler must be given access to the
rounded (to 53 bits) value of  the true infinite-precision result but
divided by 2**1536.

I don't know what the revisions-in-progress versions of 754 and 854
will require in this respect, but if they require anything along these
lines, Cowlishaw will have to play along with it if he wants to
continue claiming IBM's spec is a superset.

> If the former, decimal.Signals should at least be renamed to
> decimal.Conditions.  If the latter, decimal.py's implementation of
> exceptions needs to be reworked.

Yup, it sounds like it does need some reworking.


More information about the Python-Dev mailing list