[Python-ideas] Should decimal.InvalidOperation subclass ValueError?

[Steven D'Aprano]

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