[Python-Dev] decimal.py signals & traps
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.
* "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>
More information about the Python-Dev
mailing list