[Python-Dev] decimal.py signals & traps
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:
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999999,
Emax=999999999, setflags=, settraps=['DivisionByZero', 'Overflow',
But I'd go even further.
* "setflags" and "settraps" are awkward. How about "flags" and
* 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
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