[Python-ideas] Should decimal.InvalidOperation subclass ValueError?
steve at pearwood.info
Tue May 24 12:14:39 EDT 2016
On Mon, May 23, 2016 at 08:11:10AM +0000, Stefan Krah wrote:
> Greg Ewing <greg.ewing at ...> writes:
> > >>>So I propose that InvalidOperation be changed to inherit from
> > >>>ValueError, to match the expected behaviour from other numeric types.
> > Related to this, is there any good reason that ArithmeticError
> > doesn't derive from ValueError?
> For Decimal at least, Overflow, Underflow, Clamped etc. don't really
> map to ValueError.
I think they do. Take Overflow:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
decimal.Overflow: [<class 'decimal.Overflow'>]
Obviously that's a problem with the *value*. It's not a type error. If
the value were smaller, the calculation wouldn't have overflowed.
> This includes InvalidOperation, which unfortunately *already* has
> a subclass ConversionSyntax for the use case that came up here.
> ConversionSyntax, however, is designated by the standard to be a
> "condition" rather than a "signal", so ConversionSyntax isn't
> raised -- it just exists, and in the C version you can see the
> "condition" in the list next to the exception that was raised.
> Adding a ValueError to all that just complicates things further.
> I wouldn't mind raising ConversionSyntax directly, but then again
> no one knows about that either and it's a small deviation from
> the standard.
I don't believe the standard says anything about class hierarchies for
traps. It explicitly says:
"This specification does not define the means by which flags and traps
are reset or altered, respectively, or the means by which traps are
As far as the standard itself cares, making InvalidOperation a subclass
of ValueError is no better or worse than making InvalidOperation a
subclass of Exception.
More information about the Python-ideas