[Python-Dev] decimal.py signals & traps (original) (raw)

David Goodger goodger at python.org
Fri Jul 9 03:35:19 CEST 2004

Raymond Hettinger wrote:

The most uncomfortable part of the Python interface to contexts is creating the dictionaries for traps and flags arguments. Besides being a pain to create and display, there are issues with two contexts sharing the same underlying dictionaries. Also, it makes it difficult to address the issue at hand (as noted by the one XXX comment in the module and by your bug report).

Here's the comment:

XXX Is there a logic error in subclassing InvalidOperation? Setting

the InvalidOperation trap to zero does not preclude

ConversionSyntax. Also, incrementing Conversion syntax flag will

not increment InvalidOperation. Both of these issues interfere with

cross-language portability because code following the spec would not

know about the Python subclasses.

There's no logic error in subclassing InvalidOperation. The error is in treating the subclasses as signals: they're not. The solution is simple: don't extend the spec by making the ConversionSyntax etc. exceptional conditions into signals.

As a first step, I would like change the Context constructor API to match the format in Context.repr. That format is somewhat easier to use and less verbose (list only the flags and traps that you want set).

Yes, Context.repr is easier:

decimal.DefaultContext Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999999, Emax=999999999, setflags=[], settraps=['DivisionByZero', 'Overflow', 'InvalidOperation'])

But I'd go even further.

Also, I would add accessor methods patterned after the Language Independent Arithmetic standard (LIA-1) to set, clear, and test flags and traps.

Could you provide examples? Or a link? I couldn't find the text of the standard on the web.

The dictionaries themselves would be made private (allowing them to be recast as sets if desired).

Sure; implementation detail.

With a method interface in place, a next step would be to add logic to maintain relationships between signals. Setting the ConversionSyntax flag also sets the InvalidOperation flag. Likewise setting a trap for InvalidOperation would set the trap for ConversionSyntax.

There is no need for this.

The point of this discussion and the patch is that according to the spec and PEP 327, there is no "conversion syntax" signal. "Conversion syntax" is an exceptional condition, which triggers the "invalid-operation" signal. Same for "division impossible", "division undefined", and "invalid context"; all of these are conditions tied to the "invalid-operation" signal. Making ConversionSyntax etc. into signals would be extending the spec.

I'm less enthusiastic about changing any of the exception names but none of the above precludes that as a last step.

No name changes are necessary IMO.

-- David Goodger <http://python.net/~goodger>

More information about the Python-Dev mailing list