[Python-ideas] Should decimal.InvalidOperation subclass ValueError?
Steven D'Aprano
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:
py> Decimal("1e500000")**2
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
effected."
http://speleotrove.com/decimal/damodel.html#backref.11
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.
--
Steve
More information about the Python-ideas
mailing list