[Python-Dev] decimal.py signals & traps

[David Goodger]

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.

* "setflags" and "settraps" are awkward.  How about "flags" and
   "traps" instead?

* Rather than list traps by class name (string), why not use the
   signal classes as constants?  I.e.

       settraps=[DivisionByZero, Overflow, InvalidOperation]

   This is analogous to using the ROUND_HALF_EVEN constant in the repr.

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