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

[Stephen J. Turnbull]

Rob Cliffe writes:
 > What I was trying to say was:  I think of
 > 
 >      ValueError as applying to a single ("bad") value
 > 
 >      whereas ArithmeticError can arise from trying to combine multiple 
 > ("good") values.

I thought about that, and concluded that (1) a function taking
multiple arguments is semantically equivalent to a function taking a
single tuple as argument, and (2) offhand, I don't know of any errors
of computation that require knowledge of more than one argument to
recognize (and it's always the same argument).

I realize that there are alternative ways of interpreting those facts
(eg, in the implementation you will take the tuple apart and operate
on the components as "multiple entities").  However, I found myself
looping between those two, one or the other covered everything that
wasn't a TypeError in the first place.

 > It wouldn't be appropriate for ArithmeticError to be a subclass of
 > ValueError, because there is no single erroneous value that you can
 > point to.

Well, I *can* point to the *tuple*.  You need to argue why I
shouldn't, in view of the fact that the subclassing is correct (not
only is the tuple as value invalid, the subclassing tells me that it's
not just one of the components, but an interaction of more than one).

Examples would help.  ZeroDivisionError tells you that it's exactly
one of the arguments by its name.  Feeding a complex as either
argument to atan2 gives a TypeError.  Feeding a zero as either
argument to atan2 gives a (correct!) answer (atan2(x,y) is not the
same as atan(y/x), which raises ZeroDivisionError before atan is
actually called).  Feeding two zeros to atan2 gives an answer (but I'm
way too far from 9th grade to remember if that's correct -- perhaps
that "should" raise an ArithmeticError on your interpretation).

Steve